On Tue, Apr 3, 2012 at 10:04 AM, Rui Nuno Capela <rncbc@email-addr-hidden> wrote:
>
> jack-session has some fsck-up restrictions of its own
>
> one that i had historical complaints is about this non-reusable session
> directory restriction (here, the "non" particle, is not a pun;) which meant
> that you can't save into the same session directory twice
>
> a "really-smart/intelligent" SM could copy and re(sym)link all the
> references under each client participant's session sub-directory, yes, a
> chimeric kind of effort comes to mind :o)
>
> alas. this jack-session restriction has been somewhat circumvented by the
> "versioning" feature on qjackctl-as-jack-session-**manager, by yours
> truly. yes it's true, but it shows you how cumbersome is like when one has
> to go around and break the red tape of those draconian SM's ;)
>
> and now NSM is about asking for even more and thicker red tape...
>
> cough
>
> now, i could suggest NSM API to be split in levels of compliance and
> restrictiveness, so to speak:
>
> - level 0 :- clients just store/retrieve their own private state from a
> supplied and independent session sub-directory; no GUI File menu
> restrictions; no file location restrictions, no symlinks, no juggling, no
> dupes, no sh*t.
>
> - level 1+ :- anything that (may progressively?) imposes each one the
> mentioned non-restrictions of level 0.
>
> starting with level 0, there's a fair chance for NSM to revolve, and even
> co-exist peacefully with jack-session and ladish. call me a dreamer :)
>
>
Peacefully co-existing at the lowest common denominator of functionality
completely defeats the purpose of trying to improve the integration
experience for *users*. Remember, you only have to change the code once...
People use this stuff every day. If there is a compliance level of 0, then
developers will just pick that (you know it's true) and stop there.
As far as the restrictions imposed by NSM... NSM requires very little of
the application developer. The hardest part is if you want to support the
session 'switch' functionality, and even that is not very difficult (hey,
all the Non-* does it, so that means I had to implement it 4 times... so
why are you complaining when you haven't even tried?) The requirement that
you *not* do something is a hell of a lot easier to comply with than
requiring that you do something complicated, which is exactly why NSM
*doesn't* require applications to do anything complicated...
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Apr 3 20:15:02 2012
This archive was generated by hypermail 2.1.8 : Tue Apr 03 2012 - 20:15:03 EEST