[LAD] adding session notifications to jack

[David Robillard]

On Sun, 2009-11-22 at 00:39 +0100, torbenh wrote:
> On Sat, Nov 21, 2009 at 06:05:01PM -0500, David Robillard wrote:
> > On Sat, 2009-11-21 at 23:36 +0100, torbenh wrote:
> > > On Sat, Nov 21, 2009 at 04:37:17PM -0500, David Robillard wrote:
> > [...]
> > > > What is this unique ID?  Unique ID of what?
> > > 
> > > unique id, which is meant to persistent. a unique client id for the
> > > session. 
> > > jack_client_open is extended to accept this uuid. so upon session
> > > restore, the client will have the same uuid again.
> > > and the session manager will be able to query its jack client name.
> > > and then be able connect things again.
> > 
> > Is there a purpose to this ID other than getting the client name?  If
> > it's about client name, we should just use the client name.
> 
> what would happen if the name was already taken ?
> i basically had lash in mind when i imlemented it. 

Yeah, that kind of thing is the problem... you said it is an ID for the
session, where does the client get this ID to pass to jack_client_open?

The only thing I can see making sense is where the app passes an ID to
jack is if it's passing an ID for /the application itself/, so the
session manager could then say "ah, this session requires you" and send
it the appropriate restore command.  Multiple instances of the same app
would send the same ID, and the session manager would send them
different restore events.

> but the client name would not work, if i had a hydrogen running, and
> loaded a session with another hydrogen. 

This is why an ID for the session doesn't work either, as far as I can
see.

> > > i have added:
> > > 
> > > void jack_client_set_cookie( jack_client_t *client, const char *key, const char *value );
> > > char *jack_get_cookie_by_uuid( jack_client_t *client, const char *uuid, const char *key )
> > > 
> > > now. this allows for publishing such things.
> > 
> > Excellent.  Jack has needed a metadata system really, really badly for
> > ages.  Need to be able to set stuff for ports too though.  This could
> > elegantly solve so many long standing problems of jack (e.g. the auto
> > connect problem).
> > 
> > However, notes from a metadata nerd:
> > 
> > - The key should REALLY REALLY be a URI.  The manager (or whoever else,
> > including JACK itself) needs to be able to actually infer some meaning
> > from a "cookie", or the system isn't really that useful.  Because this
> > is persistent, and can be used to convey meaningful information, using a
> > free text (i.e. meaningless) key is an extremely bad idea.
> 
> its not really persistent. the client needs to set them.
> and i dont have means yet, to set them from another client.
> do you think thats necessary ?

I assume it would/could be saved as part of a session, so "persistent"
that way.  Either way, arguments apply since it should be "meaningful".

Clients changing properties of other clients seems like probably a bad
idea to me.
 
> > - There should probably be an optional const char *type parameter, to
> > specify the type of the value.
> > 
> > I still don't see why this uuid is needed when any existing client
> > already has a unique name.
> 
> noted above, because the client name uniqueness doesnt necessary persist
> between session loads.

The client in effect has nothing to do with anything about a session
until it is explicitly saved or restored.   I may just misunderstand
what you mean this ID to mean, but it seems really wonky.
 
> > > > But this leads me to the main point I want to make:
> > > > 
> > > > My take on this general thing is that a simple API like this is very
> > > > definitely the right path, but if anything I would like it not even tied
> > > > to Jack itself either.  The reason session management has failed to take
> > > > hold is too much implementation-defined crap, breaking APIs, complexity
> > > > to implement, and all that kind of thing.
> > > > 
> > > > How about taking it one step farther:  define this API in a single C
> > > > header, which would be very small, not tied to ANY implementation
> > > > whatsoever, and implementable by both plugins and hosts (this last part
> > > > is a very big win IMHO).  All this header would define is a descriptor
> > > > (struct) with the necessary methods.  Sort of a ladspa.h for session
> > > > management, except even simpler.  How you actually get this descriptor
> > > > would be the only implementation dependent part (e.g. a host could pass
> > > > it to a plugin, or Jack could have a single new call to return it).
> > > 
> > > interesting idea. i am not sure about the semantics of the reply strings
> > > in the plugin case though.
> > 
> > I don't understand what the reply string means.  You said "return a
> > string which specifies, how they want to be restarted".  Specifies
> > what/how, precisely?
> 
> oh... its the key to session reload.
> it basically is the command line, thats needed to get this client up
> again, and make it load its config.

Ah.  Maybe not very portable?

It seems sort of redundant to have restoring via command line when we
already have a restore callback that does that anyway.  What if instead
we give a unique ID to the application itself only(*).  Then, before
calling jack_client_open, the client must call
jack_client_set_id(myappid) so Jack (and/or the session manager) knows
what it is.  The session manager can then restore it via the usual
callbacks.  Then app authors only need to implement restore once, in the
callback, and don't have to deal with command line stuff at all (which
can be pretty annoying in some cases).  I suppose this requires that the
command line arguments of the app are basically irrelevant though, but
the appp could save those same settings to the save directory too...

Just a thought, trying to make it simpler and purely API based.

-dr

(* Pedantically, all versions of an application that are save/restore
compatible to the same directory)