On Fri, 12 Aug 2011 03:52:41 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
If session management is disabled on the default I see no problem to commit into trunk,Yeah, and we know how well that worked with the locale kit. Now we have animplementation that is far from being ready for prime time, thus being another blocker for R1, since we can't really remove it anymore. I'm sure the same will happen with any somewhat working feature, regardless of whether it is really ready.
but it involved many people to work on haiku who would not have been involved otherwise. Theoretically we could just remove the local preferences from the images to disable the local kit again and fix the R1 blocker ;-)
there are just two more hooks in BApplication. If there are no objections I would commit it soon.Please don't. As already written in the message you quoted, I think the implementation of the feature is more complex than adding two virtualmethods and the discussion has shown that there isn't even an agreement onhow session management should work
I think there were some valid discussion about profiles but the session manager is straight forward IMHO. The goal is a kind of software hibernate. How good that works depends on the applications that implement store/restore.
Also note that adding virtual methods has consequences with respect to binary compatibility (whether they are declared public (syntactically or conceptually) or not). Once they are in a release, you have to make sure the symbols remain available and are mapped correctly in future releases.
yes there should be fixed api before R1 but that should be doable in the short term , i.e. after adapting the first applications to use the new api.
Regards,
Clemens
