Re: [LAD] Summercode 2008: LASH, pt. 3

On Wed, 2008-02-06 at 15:28 +0200, Juuso Alasuutari wrote:
> Fons Adriaensen wrote:
> > On Mon, Feb 04, 2008 at 06:18:36PM +0200, Juuso Alasuutari wrote:
> >
> >> That being said, I still do favor D-Bus over OSC.
> >
> The internal
> protocol could be anything, as long as it's not a Swiss army knife that
> tries to do everything imaginable by itself.
>
> When looking at how a multi-host session would work in practice, it's
> obvious that what happens between the LASH daemons is key. This
> communication has, in my opinion, more in common with the current
> server interface than the client interface.

I think it's worth noting that at present clients, server interfaces and
the client loader all use the same protocol. Here is a list (off the
top of my head) of the kinds of information that are communicated using
that protocol:

Project names
LASH client IDs
Client type information
Command line options
Patch system client identifiers (JACK client names, ALSA client IDs)
Patch system port identifiers (JACK port names, ALSA port IDs)
Directory names
Communication addresses (Hostnames, TCP port numbers, etc)
Configuration data items
Event notifications
Save/load progress

An ordinary client would use the following:

Project names
LASH client IDs
Client type information
Command line options
Patch system client identifiers
Patch system port identifiers
Directory names
Communication addresses
Configuration data items
Event notifications

A server interface would use the following:

Project names
LASH client IDs
Client type information
Patch system client identifiers
Patch system port identifiers
Directory names
Communication addresses
Configuration data items
Event notifications
Save/load progress

A remote lashd (similarly to the loader) would use the following:

Project names
LASH client IDs
Client type information
(Patch system client identifiers possibly)
(Patch system port identifiers possibly)
Command line options
Directory names
Communication addresses
Configuration data items
Event notifications

It seems to me as though the protocol requirements are so similar that
it would be silly to have more than one.

I would also note that there is no need to have a master/slave
distinction with remote lashds.

Bob

-- 
Bob Ham <rah@email-addr-hidden>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev