[LAD] LADI

[Patrick Shirkey]

On 12/23/2009 01:32 AM, Gabriel M. Beddingfield wrote:
>
> On Tue, 22 Dec 2009, alex stone wrote:
>
>    
>>> And I can be OK with that... as long as it's in the specs that it should
>>> work this way.
>>>
>>> But at the moment, it's not well defined what is part of the "state,"[1] nor
>>> what should (and should not) be saved in a "jacksession" directory, nor what
>>> can be expected WRT portability.
>>>        
>> But it was defined. A file that showed the saved state of each app
>> present in the session, and a list of all connections that were
>> current at the time the session was saved. Couldn't be simpler.
>>      
> So, if 'Foomatic DAW' saves state with a one-liner like
> this:
>
>     <foomatic_session id='EBC429B5-373B-4840-8CCA-99FBE045EF82' />
>
> That satisfies the requirements of your sentence.
>    



Jack_session has gone a bit further already.

char *
session_callback (jack_session_event_t code, const char *path, const char *uuid, void *arg)


It's not exactly portable because it relies on the app to do all the 
work with file storage. To make it portable would require an addition to 
the yet to be written management interface. Functionality could be added 
to create a portable archive file of the session with a single click. We 
already have the path for each clients internal data folders so all that 
would be needed is to add a small function to the interface to copy them 
to a new location, and compress the complete set of files.

That seems like a quick and efficient method of enabling session transfer.

My list of requirements for the session management interface is growing 
but I'm happy to see them becoming more defined.


1: Provide options to user for handling client renaming issues with 
clients that are already running.

- killing already running  apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with via netjack
- load a new jack instance and connect it directly to the already 
running jack instance. Should be ok with a multicore and plenty of 
memory but is it possible to define a jack instance as a parent for a 
jack child instance?

2: Provide one click archive feature to allow session transfer. Copy 
client data folders to a new location, and compress the complete set of 
files.

3: Define default behaviour in a config file.


I would be very happy to have this in place and it would accomplish 
everything that I currently need for desktop session management. With 
the exception of having a jack menu on the window decorations title bar 
for each client and handle the session and connections management 
through that. With the above in place I can wait another 10 years for 
integrated desktop window manager functionality to arrive :-)




Cheers.

--

Patrick Shirkey
Boost Hardware Ltd