FRAMEWORK / PLUGIN
If i read the other posts in Discussion and in Issue Tracker ... and the whishes (my ones included)
There is a question .... what should Liqesce be for ...
It started as Joining Folders and show them to the user as a VirtualDrive.
But there are also things like ...
Space-Balancing FilesFolders by some Rules
Including FOlders whitout joining then
Starting Script in case of IDLE
Switching to ReadOnly by commandlien/API ... if no file is RW-opened
Replacing Dokan ... eventualy making our own lowleveldriver ...
..... and what ever possible comes in future ...
So ... if i bring all to one Point. ... from my sight ...
The Main Function of Liquesce is to Provide a Virtual Drive .... not more and not less ...
Everything other can be made as Plugin ... or something similar to a plugin ...
Im a "poor Scripter" and very very "BasicLevel Programmer" so im not shure if it cant be done like this or
if its not to much overhead for the benefits ... but thats up to others to decide ...
So some ideas of me ... partly posted somwhere else ... summarized here ...
LQ (Liquesce) can be build liek a 3-Tear Application.
1st we have:
- The DokanLibrary and some Framework around it with a (until now not defined) interface to next Tear.
Benfit .... in case of swapping DokanLib against whatever only this Part has to be changed ...
2nd we have:
Something like a ... call it ... Plugin Handler / DriveCreator ... simply the Heart of LQ ....
- Here we Define/Generate the VirtualDrives ...
- Hang in the Plugins (Part/Tear 3) to ... lets name it MountPoints/ VirtualFolder ....
- Generate Events for the Plugins
- Handle basic File/Folder operations of User (but this can be a Plugin too)
- Dispatch Custom-Plugin events to other plugins.
- Manage priority and coflicts between plugins
- Build the Folder/File Tree which is provided by the Plugins
at the MountPoint/VirtualFolder in the VirtualDrive.
3rd we have the Plugins:
- Here is the Real Functionality
Until now i can imagine of 2 kind of plugins:
... provide a file folderlist ... dont mather how its generated or wher it comes from
Part/Tear 2 take it and hang it in at the MountPoint of the Plugin (VitualFolder)
... dont Provide FileFolderTree
... can be triggered by Event ....
... can Trigger an event
... do something ... what ever
Possible FileFolderProvider Plugins:
JoinFolder ... thats the functionality until now ...
RealFolder ... if you want to hang in a folder as it is whitout changes
OutOfSpacePostprocessing ... Move Folders defined by Rules in case of Low space on RealDrive
StaticDataHelper ... Move FIles of defined Type to other Drive/Folder to seperate Static FIles from
frequently changed .. to support ParitySet Creation
IDLEScriptCaller ... Call a script if since a defined time there was no read and/or write activity
LiveParity ... Creat LIVE-Parity
BasicOP ... if not realized in Tear2 then it handles the ragular FileFolder operations of User
SO HMMM .... The question is ....
Is this even possible to make ....?
Is there more benefit than Overhead ... ? It means a completly new LQ ...
If its worth to think/talk about it ....
Is there realy a need for 3 Tears ... Tear 1 and 2 can possibly joined to one.
If 3 Tears how should the interface from Tear 1 to 2 look like ?
How should the interface to the plugins look like ?
What kind of collision and conflicts can occure between the Plugins ?
Ok thats enoughe for now ..........
As i wrote ... i cant code it ... i can oly make suggestions and think about some aspects ...
The rest is up to other who are MUCH more expirienced in Coding than me .....