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