[LAD] Summercode 2008: LASH, pt. 2

Juuso Alasuutari juuso.alasuutari at gmail.com
Sat Jan 26 23:23:38 UTC 2008


Here's a list of all LASH suggestions expressed so far, as well as some new 
ones. It's quite a bunch, and it goes without saying that this is NOT A PLAN; 
no sane person would actually try to cram all of these into an application. 
If my application gets chosen for Summercode I'll only be concentrating on a 
few key things (to be announced later, maybe after another brainstorm).

So, please take this as a memo, and please do comment. The internet doesn't 
contain enough ASCII yet.


Suggested changes to internal structure:

* Interact with JACK using the JACK D-Bus interface. Lashd no longer required 
to be a libjack client.
  - Jackdbus needs a port settings interface.
* Interact with LASH clients using D-Bus (change liblash's transport to use 
D-Bus).
  - What if the client has its own D-Bus event loop and wants to manually 
handle the LASH protocol? We need an option to also allow this.
* Replace liblash's server interface with a LASH D-Bus interface. LASH control 
applications no longer required to be liblash clients.
  - Requires API change.
* Certificates and encryption for communication protocol.
  - What the "communication protocol" refers to is another question...
* OSC (?)
* Server rewrite in C++.
* Client lib rewrite in GObject.

API change suggestions:

* Break it? How? When?
  - Probably unavoidable eventually.
* Remove the server interface from liblash. Controlling LASH will happen 
through a D-Bus interface.
  - Dave Robillard has expressed that the current interface separation makes 
it difficult to write a LASH control application which is at the same time a 
LASH client (Patchage).
* Mandate that LASH clients shall not modify any external port connections.
  - Actually enforce this using JACK ACL? (A partial solution, doesn't help 
with ALSA and others.)
* Make the save directory "static" to clients unless a change notification is 
sent.
* More generic patch system API.
* Use callbacks instead of current event framework.
* Add "test disk operation" function; the server can ask the client to test if 
it can actually read from and write to the specified directory.

Feature addition suggestions:

* Lashd should capture clients' stdout and stderr and keep log(s) in the 
project dir.
  - One common log file or per-client ones?
* Preserve/restore JACK settings other than port connections.
  - Make this optional; the user must be able to tell LASH to not touch any 
JACK settings.
  - Should this be the responsibility of a JACK controller app?
* Export/import session; create or unpack a tarball of the session directory.
* Light save functionality; clients can reference files outside the session 
directory.
* Managing of non-LASH apps.
* Preserve clients' X11 properties, such as window position, screen, 
workspace, etc.
* Ability to merge sessions.
* Support for multi-host sessions.
  - Should the LASH<->client protocol support this directly (socket-based 
connections), or
  - should LASH daemons on different machines be able to connect with one 
another (master session & slave sessions)?
* Save the client data in $client_dir under a sub-dir to prevent the client 
from overwriting config files.
* Support for dictating client loading order, and which other clients need to 
be loaded before a client can load.
  - Alternative solution/scheme: client priorities.
* Track naming
* Guaranteed save directory availability
* Graded saves. (Different kinds of saves? How many different kinds?)
* Networked audio (audio/MIDI ports over network).
* User interface standard recommendation (documentation).
* Automatic client installation/in-built package manager.

Juuso



More information about the Linux-audio-dev mailing list