[LAD] Non Session Management

[rosea.grammostola]

On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
> On Sat, Mar 24, 2012 at 04:19:03PM +0100, rosea.grammostola wrote:
>
>> More devs with an opinion? Fons, Torben, Paul, Emanual, ... ?
>
> I haven't used it so far (that is just a matter of limited
> time and priorities). But on reading the available docs my
> first impression is that there is some serious thinking
> behind this. There are quite a few features/choices that
> I do like/agree with.
>
> 1. The use of OSC, defining only the messages and leaving
>     the actual implementation of the OSC interfaces to the
>     application author. This instead of the all too common
>     practice of imposing the use of some library that would
>     integrate badly with the existing framework of an app,
>     duplicate existing functionality or be in conflict with
>     it, or pull in unwanted dependencies.
>
> 2. The use of jackpatch to manage jack connections instead
>     of interfering with Jack itself. It's not clear from the
>     specs, but if this means that NSM will (or can be told
>     to) leave Jack completely alone I'll like it even more.
>
> 3. Clearly defining the way an app should behave w.r.t. its
>     File menu entries (when managed). This is quite intrusive
>     to existing clients, but it is IMHO absolutley essential.
>     Kudos to the designer(s) for the having the courage to do
>     this instead of allowing application developers to take
>     the 'least effort' way (which would of course be better
>     marketing, but invite later misery).


At this point we can at least conclude that the people who have spoken 
out about session management and 'the modular approach' in the last 
couple of years and/or are involved in thinking about or building a 
session manager solution, agree more or less about the fact that NSM has 
a nice design and is probably useful in the different workflows. These 
people are, to name a few, Fons, Liles (author of NON) and Nedko (all 
though he thinks a session manager should do even more, that's what 
Ladish does. But ladish supports also JS and NSM (soon)). The JS 
developers didn't speak out clearly yet.

What could be an advantage of JS, is that it has JACK as only dependency 
and is integrated in JACK. Others however, have pointed out that not 
depending on JACK is a big plus for them or even a demand. It gives more 
possibilities to have other apps in the session.

As mentioned before, NSM seems to have some advantages JS doesn't have 
and lacks some disadvantages Ladish have (you need jackdbus). To call 
NSM a good compromise wouldn't give NSM the credits it deserves, but on 
the other hand, NSM could probably be a widely supported session API 
within the LAD/LAU community. This would be a unique situation.

It's to early to settle down our conclusions though. It would be nice if 
more developers dive into it, study the API, study the practical 
implications, use NSM and probably even try to build a patch for it into 
their program, so we could have a better overview about how developers 
think about NSM. It could be that developers prefer a other session API 
then NSM. Maybe it's good to give your arguments. It's good to have 
disagreements and unity has it's disadvantages, but for an session API 
it's also good have agreements. Actually, you need enough of them to be 
successful as a Linuxaudio session API...

Best regards,
\r