Here comes the third part of our exciting LASH trilogy. Unfortunately I lost the previous threads' mails while migrating from kmail & POP to thunderbird & IMAP, so I'll have to start yet another one.
I'd like to apologize to those whose comments and questions I might have neglected to reply to during past discussions. I've needed to concentrate on my studies for the past week or two, and have had little energy to spend here. So if anyone has something to say, please do. Here's a rough sketch of what I think should be done in what order. A lot of the stuff that came up during the discussions here is missing, and that's how it should be. This list is supposed to end up being actually doable and realistic. Remember the magic words: "For starters." 1) Switch to using the JACK D-Bus interface for lashd<->jackd communication. 2) Add a D-Bus control interface to LASH, which is supposed to eventually replace the current liblash server interface API. 3) Change the liblash client interface's internals to use D-Bus for communication with lashd. 4) Start serious work on re-planning the API (extending it or adding an alternative one) and implementing new features. Most of the things discussed so far will fall under this category, and many of the suggested feature improvements will also affect API design. When this stage begins we should have another look at what's been said so far, and what we can make out of it. I'd like to add that although this is more or less what I'll be putting in my Summercode application, things probably will, and by all means should, also evolve on their own weight. Some of the changes I listed may already be written before June; who knows, maybe we'll have sharks with lasers. And my application may not be chosen at all, but that should only matter in terms of available resources to LASH development. Thanks, Juuso _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
