On Thu, 11 Aug 2011 18:54:21 +1200, Stephan Aßmus <superstippi@xxxxxx> wrote:
*push* did this actually reached the list last time? there have been no messages on this WE, was freelist down?Your message made it through, but I guess no one responded. My opinion is to commit your change.All I remember is that the original proposal raised some substantial discussion. When I saw the new mail, I was wondering how it could address the raised issues, but didn't have time to look at it closer and I don't remember all the concerns either. I would not commit it if it doesn't take the discussion back then into consideration much. Perhaps it would help me and other people with very little Haiku time right now, if you could outline the changes made to the code in reference to (a summary of) the issues raised in the original discussion.
Basically you just need a way to store the app state and to restore it. All the other stuff like session management and profiles can be done using this functionality. For example, you could develop your own profile manager on top of it.
For simplicity, I would not differentiate to much between different use cases like profiles or deep session states. I think its already a bit annoying for the standard application developer to implement save and restore functions especially if they are not essential for a usable application. Because of that there should only the option to save the state as good as possible and to restore a saved state as good as possible. The only differentiation at the moment would be to provide a BApplicationState object that optional provides access to a session specific BIOData storage.
For the api, I'm thinking about to give mmu_man's idea to use the BArchivable Archive(BMessage* archive, bool deep) method to store the state another try. It looks more consistent to me but we still need an extra restore hook...
Will publish the code somehow else for now.
Regards,
Clemens
