On Sat, 17 May 2008 02:34:25 +0400 Fedor Gusev <[EMAIL PROTECTED]> babbled:
> Hello. > > I'm a Google Summer of Code student working on improving EFM and I > would like to share some thoughts, which my mentor (Nick Hughart) and > I have been discussing. > > The thoughts are focused on dealing with slave process. Here goes... > > == Slave process == > There are two considerations on this: > * We want to be able to run several file operations (like copy, move, > etc.) at the same time, > * We want to be able to send a progress report and receive abort > commands in the middle of operation. > > In order to achieve this, the following strategy seems reasonable. For > every operation, forced by user, a new slave process will be created. is this really the right idea? or just have the current slave process schedule itself a bit better? or have the current slave process spawn its own children to do the operations (i did consider at some point just running "cp -parv" or "mv -v" etc. etc. and reading stdout for status..). > Inside this process, an idler will scan through the directory tree and > * find out how much work is there to do (for progress reports) and > * queue files for a work idler, which will perform the actual > * operation. > After all queued files are worked out, the process will finish itself. sure - i would just make a child of the e_fm process do this work - talk back to e_fm process via stdout. e_fm proc just ipc's collect3ed status back to e. > This work idler will do copies and other operations by small chunks, > so IPC messages are able to be sent and received in the middle of > operation. > > We will need one process running always for HAL. > ==================== > > There are some thing more think throught: > > * File locking > How to deal with situation, when files in operation are modified > (deleted, moved, etc.)? ignore it. unix as such has co-operative locking semantics. no need to try and do what unix doesn't do. not in efm at this stage :) > * Handling errors > What to do with files, when an error occurres? Should everything > just go back or should the process just stop? How to make operations > atomic? good q. generally speaking you'd paus an operation (eg a recursive delete or a recursive move or copy) and then allow a "ignore this error", "ignore all errors for this op" or "cancel this now" which unrolls any partially done ops (like a partially copied file) and stops the whole op. > * History system > How to keep track of what was done? How to pass this info from slave > process to the core? What do do here with errors and abortions? as above. every action is an operation (a 'cp -r', a 'mv' a 'rm -rf' etc.). these ops each can be partly completed and if so the above holds. the ui needs to track these ops and get status on them and be able to cancel them at any point and display current progress. > * Abortions > What to do when a user forces an abortion? What does this actually > mean? unroll any partially done file copy, but otherwise leave tree of files copied/moved/deleted as-is. in the future a "rollback to beginning of opration" might be nice too - if possible. :) > I'd love to know what other people are thinking on the above. If > you're against something, please, say. Any ideas how to do these > things will be greatfully appreciated. Even your expectations (from > user's point of view) on how these should work are welcome. > > Thanks in advance, > Fedor Gusev. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
