[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