[LAD] Summercode 2008: LASH as a D-Bus service

[Juuso Alasuutari]

On Tuesday 22 January 2008 15:39:20 Nedko Arnaudov wrote:
> Juuso Alasuutari <juuso.alasuutari at gmail.com> writes:
> > - Turn LASH into a D-Bus service daemon.
>
> Do you mean lashd becoming a D-Bus service? If so, do you imagine
> having logfile like of jackdbus?

I didn't quite understand what you mean by this until I read onward. Are you 
referring to capturing clients' output, like you mention below?

> I think it is quite important what will be changes for users of
> LASH. The things you mentioned are changes either to internal
> implementation or API. IMHO, all changes should be driven by desire to
> solve current problems that LASH user have (as human using the whole
> thing, not as API user). Thus problems that people have with LASH should
> be taken into account. Here are my problems with LASH:
>
>  * auto-launching without logfile means no proper handling of lashified
>    apps stdout/stderr. It should have logfile, with prefixing output of
>    apps.

Capturing the clients' debug messages would indeed be helpful. How do you 
think it should be handled?

One option would be to add a logging method to the API that the clients should 
use. But as with most other client requirements, there's no way to control 
that they actually behave correctly (think of loading and saving files 
correctly). And even if they do, then what about other messages than those 
deliberately put into the code, like e.g. GLib errors?

Idiot-proof capturing of stdout/err could probably only work if the client 
process was executed from a wrapper. It could be accomplished with the D-Bus 
service file, though. If all clients' service files would be mandated to 
include something like "Exec=/usr/bin/lash_exec /usr/bin/foobar", then... 
Umm, at least we could redirect the streams _somewhere_ -- but what to do 
from thereon, I'm not sure.

>  * lash is of mercy of libjack and crashing jackd often causes lashd
>    kill. This is just wrong. lash should be able to restart jack, tell
>    jack apps that jack server is started again so they can reconnect to
>    jack server and finally lash can restore jack connections.
>  * lash should preserve at least basic properties of currently started
>    JACK server, such as sample rate and availability of hardware
>    ports. When loading session whose JACK parameters dont match, user
>    should be given options what to do.

This is where I believe we both agree that turning LASH into a D-Bus service 
will help. The session handler shouldn't be a JACK client; instead, the audio 
server should be a D-Bus client of the session handler, although a Very 
Special one. And that's something that the JACK D-Bus control interface will 
enable.

>  * there is no export/import "tarball" (single file) functionality, to
>    be used for backup of sessions and transfering them between machines
>  * lash apps should be allowed to do "light save", with app session
>    referecencing files/resources external to lash. This means for
>    example that such lash light save should not copy ardour wav files
>    that are linked (not copied) to lash directory.

These sound like they could be useful features. However, I feel that we should 
settle on the more basic issues first.

>  * lash should be able to manage not lashified apps at least to extent
>    of launching them and connecting their ports.

I'd say this sounds OK.

>  * there is no good GUI for controlling lash. probably [wm]glashctl
>    fixes this. lash_panel use is PITA. Usable GUI should be part of the
>    lash tarball. Also, X11-less operations should be still possible
>    (command-line or ncurses).

None of my business... :) (On the other hand, it's important to distinguish 
between features which only concern the UI and those that affect API design.)

>  * lash does not preserve X11 related properties of apps, like on what
>    screen (dual-head) they were.

Are you really sure that this one is worth the effort? Sounds to me like an 
awful long detour from managing audio sessions.

>  * when opening/importing session, lash should be able to either replace
>    current session or merge it, to allow combining several simpler
>    sessions into more complex ones

This is high tech, and as such it sounds tempting. Too tempting to be 
considered at this point.

> Things that I'm not personally interested on (I don't think they worth
> but there is nothing wrong if support for them is there, unless this
> makes implementation much more complicated and thus bug-prone):
>
>  * Supporting connections for things other than JACK (read ALSA seq)

The current LASH already handles ALSA Seq connections, and I think it's fair 
that the D-Bus implementation would, too.

>  * Supporting multi machine sessions (several machines in a network used
>    in common session).
>  * Creating "universal" fit-all solution that works for every single app
>    on every single OS and thus, not being able to it at all using
>    available resources. This does not mean that support for other OS-es
>    should be avoided intentionally. Still, I need *Linux* Audio Session
>    Handler, not LASH Audio Session Handler.

Please, you're confusing me. ;)

> I plan to donate my time to fixing LASH, after I (with Juuso's and
> Marc's help) finish with jackdbus (patchbay and transport control
> interfaces are still mising). I'd like everybody who has problems with
> current state of LASH to write them in this thread.

I plan to continue working on jackdbus which is an important part of this 
whole scenario. But until the winning applications are announced I'll refrain 
from any actual LASH coding; I need to know the level of commitment I can 
afford to make before I take on a task this big. I will need to hash things 
out on a conceptual level beforehand though, as it's hard to pull a realistic 
and credible development plan solely out of one's back pocket.

At this point I believe it would help to categorize the different sub-goals. 
What issues are purely in the domain of API design, what are the things that 
the daemon must handle, etc. I'll start sketching these and getting familiar 
with what we have now, then post some sort of rough draft. In the meantime 
I'll be happy if anyone wants to comment on the questions above.

Juuso