On 11/22/2009 01:45 AM, Paul Davis wrote:
On Sat, Nov 21, 2009 at 12:18 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Nedko has chosen to work with dbus and has
provided a very flexible
system built on that decision. However his approach is not acceptable
for all use cases. Afaict there is very little interest from parties
that disagree with the dbus approach to enhance the LADI toolset in a
way that makes it more flexible for their use and vision.
I don't really care at all about the technology inside a Linux session
handling "toolkit", although clearly it would be nicer if it worked on
all Linux systems. What I care about is the complete lack of any
stable API that a developer of an application that would participate
in this could use and have some confidence in. Do I believe that using
dbus as an IPC mechanism makes sense in this case, and that therefore
"the API" is really just a set of dbus names and semantics? Well, i'm
agnostic about that (my doubt comes from the fact that the
participants are all already connected via an existing IPC mechanism
that is guaranteed to be running; its called JACK), but in the end it
does not matter much to me - what matters more is that the work to
integrate an application into the system can be done, and stay done.
My impression of LASH and its cousins is that this simply hasn't
happened yet.
I think this is why Nedko has decided to draw a line here. He has
attempted to provide a very flexible and powerful implementation built
on top of several other implementations. The big problem is that
developer community is not getting on board.
If we gave more support to the LADI tools as a session management option
then we could get feedback on the capabilities of the toolset from the
wider community of users and get a better impression of how far from the
target we really are.
If jack1/2, qjackctl, patchage, gnome, kde, etc... don't get behind it
as a viable session management option then we will never fulfil the
potential.
Patrick Shirkey
Boost Hardware Ltd