On Sat, Feb 23, 2013 at 5:05 PM, Johannes Kroll <[email protected]> wrote:
> On Sat, 23 Feb 2013 19:47:26 -0500 > Paul Davis <[email protected]> wrote: > > > On Sat, Feb 23, 2013 at 7:32 PM, Johannes Kroll <[email protected]> > wrote: > > > > > > > > Could you elaborate please: why is compatibility between the existing > > > session management systems a dumb idea? > > > > > > you don't compatibility between DECnet and BITNET. you don't get > > compatibility between english and chinese. what you get is a *new* > > system/protocol/language. > > > > <ob-xkcd> > > http://xkcd.com/927/ > > </ob-xkcd> > > You and David do not understand what I'm proposing. My intention is not > to create a new protocol. Creating another system because there are > already too many would be indeed idiotic: that's what has been done > before with the other session managers. I imagine creating *something* > that makes the existing systems work together, *without* changing the > clients that use the existing systems. > > I.e. one app may be thinking it's talking to non-session, one app > speaks ladish, another thinks it's talking to jack-session, but in > reality they all talk to one session manager which implements all 3 > (4... 7... umpteen) protocols. > > I have not looked at the implementations of the existing systems. Maybe > what I'm proposing is not easily possible. In any case, I want you to > understand that I'm not proposing to increase the number of systems in > order to decrease the number of systems. That would be, indeed, dumb in > a painfully obvious way. > > 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.
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
