27 Jan
2008
27 Jan
'08
6:33 a.m.
Juuso Alasuutari <juuso.alasuutari(a)gmail.com> writes:
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).
Great work so far! Having those in one place is quite useful. It allows
easy spoting of common goals where developers can cooperate.
So, please take this as a memo, and please do comment.
The internet doesn't
contain enough ASCII yet.
I'll use -5 .. 0 .. +5 numbers to express how well each things fits my
personal view.
Here they go:
Suggested changes to internal structure:
* Interact with JACK using the JACK D-Bus interface. Lashd no longer required
to be a libjack client.
fit: +5
- Jackdbus needs a port settings interface.
what is this? the patchbay interface? I.e. connect/discconect ports, get
clients/ports, get current connections, get notifications about graph
changes?
* Interact with LASH clients using D-Bus (change
liblash's transport to use
D-Bus).
fit: +2
- 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.
Here I'm affraid of some technical problems. What if app uses some dbus
binding that hides everything? And how lash dbus code will be executed
in app using glib/qt bindings. Also I expect other audio related dbus
functionality to become more widely used and we could try to coordinate
this now:
* http://ll-plugins.sourceforge.net/dbus/midiinput.html (curently bound
to JACK MIDI, but easlity extendable).
* JACK Synthesizer Manager Proposal (using D-Bus)?
* Replace liblash's server interface with a LASH
D-Bus interface. LASH control
applications no longer required to be liblash clients.
- Requires API change.
fit: +4
Given the low availablitity of such applications (about 3 of them, some
of them probably in stalled state), I'd be bold here.
* Certificates and encryption for communication
protocol.
- What the "communication protocol" refers to is another question...
fit: +1
D-Bus authentication mechanisms should be used here probably.
* OSC (?)
If for lash client <-> lash server protocol:
fit: -1
* Server rewrite in C++.
fit: +2
* Client lib rewrite in GObject.
fit: -2
I'm against using GObject, not against making it more OO internally.
* Server rewrite in Python
fit: +4
* Strip support for ALSA (make LASH - JACK specific)
fit: +2
API change suggestions:
* Break it? How? When?
- Probably unavoidable eventually.
fit: -5
Don't break current client API. We have have enough lashified apps we
know about and nobody knows how much lashified apps we dont know about.
Still we should make alternative client interface to be used in new
apps. Existing lashified apps can be switched to the new api if someone
has motivation to do this. Still we cannot be sure that we know all
existing lashified apps. Also, this will fsck up distro packagers, with
result being low adoption. IMHO, if we provide better alternative API,
most developers will use it instead (in most cases). Thus:
* Provide new *alternative* API:
fit: +4
* 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).
fit: +4
* 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.)
fit: +4
* Make the save directory "static" to
clients unless a change notification is
sent.
What is this?
* More generic patch system API.
What is this?
* Use callbacks instead of current event framework.
fit: +3
* 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.
Why is this needed?
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?
One common per-user (lashd is per-user process) log file.
Use prefixes to distinguish between each client output and
stdout/stderr.
fit: +5
* 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.
fit: +5
- Should this be the responsibility of a JACK
controller app?
fit: -3
- LASH being able to restart JACK server in the bad thing
happens. The same way it can restart lash clients.
fit: +5
* Export/import session; create or unpack a tarball of
the session directory.
fit: +4
* Light save functionality; clients can reference
files outside the session
directory.
fit: +4
* Managing of non-LASH apps.
App internal state is not saved but connections are restored and app is
relaunched on crash.
fit: +3
* Preserve clients' X11 properties, such as window
position, screen,
workspace, etc.
fit: +1
* Optionally preserve some important environment variables
(configurable which ones)
fit: +4
* Ability to merge sessions.
fit: +2
* 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)?
fit: +1
I think it will be better if there is dedicated master-slave protocol.
* Save the client data in $client_dir under a sub-dir
to prevent the client
from overwriting config files.
I dont get what should be really achieved by this. The proposed solution
looks like cheesy workaround for a real problem. If you want true
isolation, provide a filesystem access API as part of the LASH
API. Another option can be using chroot but this is even more insane.
fit: +0
* Support for dictating client loading order, and
which other clients need to
be loaded before a client can load.
- Alternative solution/scheme: client priorities.
fit: +2
What is difference in operation of two proposed schemes? Do they differ
only in used terms? Term "order" looks better to me, than "priority".
* Track naming
fit: +2
I think this can be combined with "merging sessions". I.e. tracks being
subsessions.
* Guaranteed save directory availability
What is this?
* Graded saves. (Different kinds of saves? How many
different kinds?)
How is this different from "light save" + "export"?
* Networked audio (audio/MIDI ports over network).
fit: +1
* User interface standard recommendation
(documentation).
fit: -5
I dont think this is in the scope of LASH.
IMHO, such plans fit much more to PHAT project.
* Automatic client installation/in-built package
manager.
fit: -5
NWO is not the solution, it is a plague.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>