[LAD] Interoperability between session management systems

[J. Liles]

On Sat, Feb 23, 2013 at 8:09 PM, hermann meyer <brummer- at web.de> wrote:

>  Am 24.02.2013 04:15, schrieb J. Liles:
>
>
>
> On Sat, Feb 23, 2013 at 6:34 PM, Johannes Kroll <jkroll at lavabit.com>wrote:
>
>> On Sat, 23 Feb 2013 17:28:49 -0800
>> "J. Liles" <malnourite at gmail.com> wrote:
>>
>> > All of the existing session management protocols have inherent
>> limitations
>> > which I was attempting to avoid by creating NSM. Nedko and I have
>> discussed
>> > including NSM protocol support in LADISH, which would be kind of like
>> what
>> > you're talking about, but the problem remains that the whole would be a
>> > lowest-common-denominator of functionality. Now, if jack session and
>> LASH
>> > and LADISH level 1 applications eventually fade out and move to the NSM
>> > protocol, then maybe that's OK. But in the meantime it's not going to
>> be as
>> > functional as using pure NSM.
>>
>>  Please, don't turn this into a "which session manager is the best" war,
>> that's not what I intended. Surely each coder thinks *their* session
>> manager is the best one, why else would they have written it. In
>> reality every SM has their strengths and weaknesses I guess. (For
>> example I noticed that NSM, which I otherwise like, can't restore Jack
>> connections without an external tool like jack_patch - and with the
>> tool, it doesn't seem to restore MIDI connections).
>>
>> About shell scripts (David): that sounds like the lowest common
>> denominator approach, and while it's neat and UNIXy and everything,
>> unless I misunderstood, writing shell scripts to start apps is what I
>> can do anyway, without any session manager. Also, I think the ability
>> to tell apps to save state while they are running is important, and
>> shell scripts can't do that.
>>
>> I would hope that something more than the lowest common denominator
>> approach would be possible. As I understand it, all SM systems do the
>> following, in one way or the other:
>>
>> 1) start apps with a saved state (may be implemented using 2)
>> 2) tell running apps to load their state from a given session
>> 3) tell apps to save their state to a given session
>> 4) possibly restore JACK and alsamidi connections
>> 5) possibly implement parts of the session loading and saving (this
>> might be completely up to the apps)
>>
>> If that's basically what SMs do, it should be possible to create an
>> interoperability layer (*NOT* a new protocol!) that talks the
>> existing protocols and does the necessary things. There might be
>> tradeoffs, when one SM system has less functionality as the other, but
>> that would hopefully only affect the apps using that SM system, not the
>> others. So it would not be "lowest common denominator".
>>
>> If the differences between SMs are that great that doing this isn't
>> possible at all, that would be sad, because I don't really see any SM
>> becoming the defacto standard any time soon.
>>
>
> I'm not starting a war. Many of the other SM protocols were designed with
> full knowledge of their limitations and compromises (that is to say, the
> authors don't believe they are the best solution by any means, just a
> workable one). In fact, the differences between the different SM protocols
> are great, and in the case of NSM even greater. Drobilla, with mention of
> shell scripts, was speaking only of a session disk format that could used
> to port existing sessions from one SM to another. If we add NSM support to
> LADISH, that will be exactly what you desire. One SM front end that
> supports every extant protocol. However, I believe this will hardly make
> the situation any easier on the *user* than it is now (and since when are
> people happy with LASH etc?). LASH, jack-session and LADISH Level 1 are
> extremely limited, and, IMHO inadequate protocols. Continuing support for
> them does nothing to enhance the user experience. And it isn't as if we're
> talking about 100s of client applications here, there are only a handful
> that support any kind of SM protocol period. I may have the desire to patch
> everything to support NSM, but what I do not have is the time (and the time
> I might spend adding NSM support to LADISH might better be spent converting
> jack-session and LASH clients over to NSM). In any case, patching will do
> far more good than talking!
>
>
>   I stated it out already in a other thread: without ever been released
> as NSM (means available as tarball, or what ever, with ONLY NSM included),
> I wouldn't support it.
>

This is stupid. What difference does it make what other programs are in the
source repository? Distributions can and should package the programs
individually. Also, NSM clients require from the NSM server implementation.
There is no libnsm to link to etc. This is the definition of a non-issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130223/72c9f596/attachment.html>