[LAD] Summercode 2008: LASH, pt. 2

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Jan 27 04:15:02 2008