[haiku-development] Re: session manager

On 2011-08-05 at 02:47:50 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx> 
> On Tue, 28 Jun 2011 02:14:48 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> > Anyway, I'd strongly recommend not to start developing this feature in
> > the
> > trunk as it seems to be quite a bit more complex than adding two new
> > hooks to
> > BApplication.
> I finally looked into it again and reworked it a bit. It is right that
> most applications have to implement these two methods to make it work
> probably but I would not see any big problems to develop it in the trunk.
> I think people would have it easier to adapt existing applications if
> session manager is already there. I doubt somehow that this would happen
> if the feature is somewhere in a branch.

If you want to push this feature, do that. But please in a branch (or 
better in a GitHub/Gitorious clone). Dropping some unreviewed framework in 
the trunk and inviting people to use it is the wrong way.

> At the moment a session is automatically saved on shutdown. The restore is
> done by putting a "hey registrar '_RLS'" (restore last session) into the
> boot script. Thus this is optional. If there are more problems I could
> also make the saving configurable...
> 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 an 
implementation 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.

> 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 virtual 
methods and the discussion has shown that there isn't even an agreement on 
how session management should work.

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.

CU, Ingo

Other related posts: