<br><br><div class="gmail_quote">On Sat, Feb 23, 2013 at 5:05 PM, Johannes Kroll <span dir="ltr"><<a href="mailto:jkroll@lavabit.com" target="_blank">jkroll@lavabit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sat, 23 Feb 2013 19:47:26 -0500<br>
Paul Davis <<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>> wrote:<br>
<br>
> On Sat, Feb 23, 2013 at 7:32 PM, Johannes Kroll <<a href="mailto:jkroll@lavabit.com">jkroll@lavabit.com</a>> wrote:<br>
><br>
> ><br>
> > Could you elaborate please: why is compatibility between the existing<br>
> > session management systems a dumb idea?<br>
><br>
><br>
> you don't compatibility between DECnet and BITNET. you don't get<br>
> compatibility between english and chinese. what you get is a *new*<br>
> system/protocol/language.<br>
><br>
> <ob-xkcd><br>
>    <a href="http://xkcd.com/927/" target="_blank">http://xkcd.com/927/</a><br>
> </ob-xkcd><br>
<br>
</div></div>You and David do not understand what I'm proposing. My intention is not<br>
to create a new protocol. Creating another system because there are<br>
already too many would be indeed idiotic: that's what has been done<br>
before with the other session managers. I imagine creating *something*<br>
that makes the existing systems work together, *without* changing the<br>
clients that use the existing systems.<br>
<br>
I.e. one app may be thinking it's talking to non-session, one app<br>
speaks ladish, another thinks it's talking to jack-session, but in<br>
reality they all talk to one session manager which implements all 3<br>
(4... 7... umpteen) protocols.<br>
<br>
I have not looked at the implementations of the existing systems. Maybe<br>
what I'm proposing is not easily possible. In any case, I want you to<br>
understand that I'm not proposing to increase the number of systems in<br>
order to decrease the number of systems. That would be, indeed, dumb in<br>
a painfully obvious way.<br>
<br></blockquote><div><br>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.<br>
<br> </div></div>