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

On Tue, 2008-01-22 at 15:39 +0200, Nedko Arnaudov wrote: You're right, but it shouldn't be worked around. If energy is going to be expended on this problem, it should be expended on fixing jackd such that it doesn't crash in the first place. If you start working around problems with JACK, I can envision a situation where there is little motivation to fix bugs in JACK because the cost of its crashing is so low. More generally, LASH isn't a frontend for JACK. LASH (when controlling JACK clients) relies on services that JACK provides. This isn't a bad thing. The focus shouldn't be on taking control of jackd through LASH but in making jackd more server-like, such that you don't need another server just to control it. This is outside the scope of LASH. Applications themselves should cope with JACK parameters that don't match their saved state. They need to cope with that regardless of LASH. The problem here is that there's no way to know which ports belong to the app. Nor should it. The X11 system is nothing whatsoever to do with LASH, intentionally. From LASH's perspective, anything to do with X11 is entirely the client's responsibility. Adding X11-specific functionality into the protocol, the server and the library should not happen. Providing convenience functions to clients is a solution, eg lash_x11_get_state_configs() and that returns a set of LASH configs containing the state of the X11 system. And, of course, functions to restore the state. But it should be separate from LASH itself, eg, in some liblash-x11. LASH already does support ALSA seq. Future support would be connecting via netjack, or firewire, or $next_big_thing. Bob -- Bob Ham <rah(a)bash.sh>