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

Juuso Alasuutari &lt;juuso.alasuutari(a)gmail.com&gt; writes: Do you mean lashd becoming a D-Bus service? If so, do you imagine having logfile like of jackdbus? 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. * 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. * 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. * lash should be able to manage not lashified apps at least to extent of launching them and connecting their ports. * 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). * lash does not preserve X11 related properties of apps, like on what screen (dual-head) they were. * 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 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) * 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. 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. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>