Be welcome, to add your opinion and idea below.

Having tried to use jack-session for a while, my conclusion is:

• It needs Session Load without application-quit, thus I'm distinguishing here
  between “quit” ⇒ exit application and “close” ⇒ close documents without application-exit.

• It needs Session Close without Save (this won't exit (most) applications)

• Beeing able to load multiple sessions (at once) appears bad, is an error-source

• Conditions where connection-restoration fails - must be known (e.g. apps are not allowed to auto-connect jack-ports)

• sometimes eventually you don't want a JS-capable app to be part of the current session, although you're running it at the same time. JS should offer a flag for this (set by jack-client-app on user request): session_client→part_of_active_session = false; (default is true, of course)

// extend EventType:
enum JackSessionEventType {
	...
    JackSessionCloseAndLoadNew = 4,
    JackSessionCloseWithoutQuit = 5
}

// extend jack-session-client implementations:
//
if( ev->type == JackSessionCloseAndLoadNew ){
 
	// close current document(s), eventually ask the user, if he/she
	//      would like to save first (but **don't quit** the application)
 
	// then load new session-document(s)
}
 
 
if( ev->type == JackSessionClose ){
 
	// close current document(s), eventually ask the user, if he/she
	//      would like to save first
 
}

- saving a command line with the session is a very bad idea.

My suggestion:

The jack-session-commander (e.g. qjackctl) has a small (operating system specific) database.
The contained entries would overwrite the command_line, if existend. Thus backwards compatible.

The database would be queried by appID:

It would have the fields: appID, executable, generic_parameters
The database can be processed with simple split(),trim() operations. One entry per line.

One single entry would look like: (fist word is the appID, not the executable name, although it may be equal.

amSynth; exe==/usr/bin/amSynth; param:loadFile1==-f synth.ams; param:uuid==-u $arg:uuid ; param:autoconnect==-A $arg:autoconnect; param:with_gui==-w $arg:with_gui;

jack_session_event would be filled by the JS-client as:

jsEvent->appID = "amSynth";
jsEvent->appParams = " loadFile1==%s; autoconnect==%s " %( sessionFile, false );
jsEvent->appFileName = sessionFile;

The jack-session-manager would search the database for the appID and generate an appropriate (os-specific) command_line.

This would also allow different command lines, by assigning different appIDs to a single application (amSynthWithoutGui, amSynthWithGui, amSynthInGreen,…)

// in 
struct _jack_session_event {
 
	// make the command_line member deprecated
 
	// introduce the following members instead
 
 
	// AppID : usually equal to application name, without path info
	char *appID;	
 
	char *appParams;	// additional prefered Application Parameters (abstracted, to be OS-independent)
 
	char appFileName;	// file to load (with extension, without path info, could contain a simple string, with more files to load.)
 
}

We need a jack-session-api best-practice section. This would contain hints as:

• dont's use paths in the command_line (amSynth vs. /usr/bin/amSynth )

• don't use single character parameters in the command_line =⇒ bad:
  params -a=yes and -A=no is the same on some platforms, rather –autoconnect=yes, –artefacts=no

• apps are not allowed to auto-connect jack-ports

• apps are not allowed to auto-connect jack-ports, when using jack-session (user option)

• apps are allowed to save to another folder additionally (for backup purposes)

• none yet