Hi Rostislav,
it seems there is demand for this feature. :)
It's good that now the locking mechanism issues have been sorted for this
release because that would prevent concurrent access to the data. Now we
have several options.
The data can be modified only when someone puts a write lock on it. Until
the lock is released, no-one can get either read or write lock. I guess, if
the auto-saving would be scheduled for this time, that thread would simply
block until the write lock is released. This can be good, but it assumes
that the applications lock the images only for the actual time when they
are modifying the data.
Other option is that the auto-save thread creates its read accessors
manually with the "IgnoreLock" option (not using the ITK access functions).
Then the auto-save thread would not block, but it will need to listen to
the modifications of the input data and restart the saving process when it
happens. Or clone the before the saving. Not much better, although there
less chance that the data is modified during cloning.
I would go for the first option, because that is simpler. Then either
people can fix there apps if the blocking occurs, or we can go for the more
complicated and hacky way with the IgnoreLock flag and listening to
Modified events.
What you think?
Cheers,
Miklos
On 15 October 2014 13:15, Khlebnikov, Rostislav <
[email protected]> wrote:
> Hi Miklos,
>
> This goes in line with my earlier email regarding the incremental saving
> (meaning saving only the stuff that changed since the scene was opened). I
> believe that implementing this is relatively important before implementing
> auto-save as it will speed up the saving process significantly and will
> reduce load on the hard drive. At least in my case where 80% of the project
> file is the original image data that never changes.
>
> I will start working on this very soon - I wanted to wait until the new
> release but likely I will just start working on this in the current master
> if it builds correctly.
>
> I guess we could work on this in parallel. It'd be great if you could
> figure out how to handle new changes to data nodes while they are being
> auto-saved in a separate thread. Should a data clone be made (likely too
> much memory consumption)? Should the writers support interruption of the
> saving process? What do you think?
>
> I would then concentrate on supporting the separate "open project" and
> "import data" actions, support for time stamp tracking to detect what
> really changed, and re-packing only changed data on save.
>
> How I saw the auto-save working then was - "open project" - save the
> location of temp folder used for scene loading as well as record that in
> the persistent storage using QSetting-like mechanism. During work - save
> the changes to this folder (will also speed up the normal saving process as
> only changes since last auto save would have to be written to temp folder
> and packing would have to be performed). On fresh start - check if the exit
> was clean and if temp folder saved in persistent storage is available - try
> to recover the scene from there.
>
> That's a big email I wrote :) Anyway - it'd be nice to hear from you as
> well as MITK core developers with thoughts on this.
>
> Rostislav.
>
> > On 15 Oct 2014, at 12:38, "Miklos Espak" <[email protected]> wrote:
> >
> > Hi All,
> >
> > is anybody interested in an auto-save feature for MITK?
> >
> > I thought of saving the project at regular interval and restore it if
> the application is restarted after a "non-clean" termination. :)
> >
> > Regards,
> > Miklos
> >
> >
> ------------------------------------------------------------------------------
> > Comprehensive Server Monitoring with Site24x7.
> > Monitor 10 servers for $9/Month.
> > Get alerted through email, SMS, voice calls or mobile push notifications.
> > Take corrective actions from your mobile device.
> > http://p.sf.net/sfu/Zoho
> > _______________________________________________
> > mitk-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/mitk-users
>
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
