On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola <[email protected]> wrote:
> [quote=Liles] > Currently one of the strong points of NSM is that applications with heavy > state (e.g. large audio files) know *exactly* where to put the state at the > time they join the session. This eliminates the need for undesirable hacks > with just storing a link to the heavy state (as was generally required with > LASH). I felt like this was one of the primary requirements of Non-DAW which > was not addressed by other session managers. > [/quote=Liles] > > (Assuming that this ^ is because of the strict opening and saving rules of > NSM). > Liles compares here with LASH, undesirable hacks are not needed anymore. > Why is this a primary requirement? Because LASH was designed with the assumption that all client applications would either: 1) Store all their state in memory and be fine with just dumping it to disk when the save yourself message came. 2) Naturally store their heavy state in some random place (like QTractor?) Programs with heavy state closely associated to the individual projects (like Non-DAW and Ardour) had to work around this by just storing the project data in some random place and only storing a reference to it in LASH, which was terrible from a consistency perspective because the user really had no idea where their data was. I want to have my sessions laid out on disk in a very specific way, with none of them named after GUIDs, and no applications/data being (mis)directed to a session just because it happened to be the last one active. With NSM (this is part of the server implementation and not the protocol) the user can lay things out on disk however they like, organizing their sessions in any way they want (including doing fancy things with subdirectories and symlinks) *and* have an expectation that e.g. the audio they record in Non-DAW after adding it as a client to a session *actually goes into the session directory they defined when they created the session*. If I want to back up my audio partition, I should not have to track down gigabytes of data from some hidden directory in $HOME that is only referred to inside incomprehensible XML files as well. The matter is complicated by applications which have been attempting to do their own crude form of session management. But here's the key point: It is only reasonable to expect an application to adhere to *one* system of session management at a time. So, if the application is connected to NSM, it should behave in a way consistent with other NSM capable applications, and if it is connected to XSM, JackSession or LASH, or what have you it can do whatever those systems allow (which is totally undefined anyway). > Moreover LASH isn't seen as a serious candidate anyway these days. I would > rather see a comparison with JackSession in this area. In other words: > > How JackSession does this and why is it, or why it is not, a problem to not > have these strict rules for applications which are in a session. I believe JackSession was intended to be the bare minimum required to transmit a 'save' message to JACK applications... Just a very basic protocol. Doing anything more to ensure a smooth and consistent user experience is outside of its scope. A lot of this behavior depends on the implementation of the Session Manager server itself, but JackSession by its nature has some basic limitations that exclude the possibility of the kind of features NSM has, so a server implementation for it can only do so much... _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
