[LAU] Session management with NSM

[Philipp Überbacher]

On Wed, 3 Sep 2014 17:27:11 -0700
"J. Liles" <malnourite at gmail.com> wrote:

> On Wed, Sep 3, 2014 at 2:08 PM, Philipp Überbacher
> <murks at tuxfamily.org> wrote:
> 
> > On Wed, 3 Sep 2014 20:27:11 +0100
> > Harry van Haaren <harryhaaren at gmail.com> wrote:
> >
> > > On Wed, Sep 3, 2014 at 7:57 PM, J. Liles <malnourite at gmail.com>
> > > wrote:
> > > > workflow that is already supported just fine by dealing
> > > > with it 'manually'.
> > > Yes, manually setting JACK before starting a session is the only
> > > and best solution that scales. As you mentioned, transporting a
> > > session to another machine would mean JACK's settings get borked:
> > > therefor this is *not* something NSM should worry about, or
> > > implement.
> >
> > I completely disagree. Moving the session from one machine to
> > another may be one use case, but a rather special one. At least
> > it's not something I would do.
> > On the other hand, remembering which jack settings are required for
> > which session is something that NSM should remember for me.
> > And given that I proposed the jackstart client as an optional
> > client, something you can use or not use, same as jackconnect, your
> > argument falls flat on its face since you could just not use the
> > jackstart client and still handle jack manually.
> >
> > You would also not need to start all clients in a pre-defined order,
> > you'd just need to make sure that jackstart starts before all
> > others.
> >
> 
> The complexity isn't much less if it's only one client. And then NSM
> needs to know to treat that client specially...

That part was clear pretty much from the start, as you can see from the
discussion between Harry and me.

> > And be honest about one point: How many clients manage to 'live
> > switch'? I guess that most don't. Even if they do, what's the cost?
> > A few seconds at session switch time at most, which is completely
> > negligible IMHO. I know that for you this is a feature that is
> > important because other session management systems don't do it, but
> > I seriously doubt that it matters for any other reason.
> >
> 
> You can lead a horse to water...

Ad hominem.

> People said the same thing about kernel suspend to RAM/disk. Yes, it
> took a while to get everything working and there are still some
> drivers that don't cooperate, but once you've seen the light you
> won't want to go back to rebooting ever again. Seems like the dark
> ages now.

You can keep this red herring.

I've made my suggestions with the goal to improve the user experience of
nsm, take the or leave them.

Regards,
Philipp