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

[Nedko Arnaudov]

Juuso Alasuutari <juuso.alasuutari at gmail.com> writes:

>>  * 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.

I was thinking about "sending" client stdout/stderror to log file (with
prefixing). I dont think we need to require registering of one dbus
service per lashified client (autolaunching). Also IMHO there is nothing
wrong with just capturing stdout/stderr of launched clients. Of course,
liblash (dbus version) will start lash service to provide "callbacks" for
the lash API.

>>  * 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.

Yes, except that I was thinking about not trating JACK server as LASH
client. Instead LASH should directly support and have special handling
of JACK server.

>>  * 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.

What are they? :)

> 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.

If you are talking about the liblash API, I'm oposed to breaking
it. OTOH, I think we could extend it or provide alternative API. We dont
need to kill lash pupil apps, right? :)

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080122/e7c9a8c4/attachment.pgp>