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

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

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