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

Juuso Alasuutari <juuso.alasuutari@email-addr-hidden> 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>

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