23 Dec
2009
23 Dec
'09
6:25 p.m.
Nedko Arnaudov wrote:
Hi Bob,
thanks for commenting on LADI stuff
Thanks for your explanation Nedko. It is clear to me that you see D-Bus
as the best practical solution at the moment. But that you do not
necessarily stick with it for always. You are open for discussion
which is good in my opinion. Others seems to think that D-Bus is not
the solution for an session handler for Linux audio. It doesn't have to
be bad to have different opinions or different ways to solve a problem.
Nedko, is LADI an project of your own, or are you willing to collaborate
with other developers who might have interest in the project? Do I
understand it right that characteristics of LADI are still open for
discussion?
Maybe it aint that bad to have two types of Session handlers for Linux.
The LADI approach and another approach without D-Bus. It's not bad to
have choice as user and maybe someone needs the features of LADI and
others features of more minimal session handlers.
Till now, LADI seems to be the only project that has reach an status so
that it actually works and is useful for musicians. Other projects seems
to be ideas on paper, nothing practical useful yet.
As a user I'm hoping that LADI will become an success, cause at the end
we really need an workable session handler. On the other hand I also
hope that people like Fons, Bob, Torben and David are able to release an
session handler without D-Bus. They have proven to have good ideas and
programming skills.
I think it will be good to have as much as consensus and especially
collaboration as possible. It would be good if others join the LADI
project I think. But I can't say which project goals are somewhat close
to the LADI project goals. Someone said that Torbens ideas could be
implemented or used in LADI in some way maybe. Then it would be good
maybe, to have a good (privat) discussion between the developers (at
least Nedko seems to say he stands open for that).
And what about the other ideas? Is there a chance that David, Fons, Bob
and others could find consensus between each other for a non D-Bus
solution? I think everyone would agree that collaboration should be
preferable here.
Today there is only one choice and that is LADI, so I'll test that first
and hope it works good enough for me so that at least I don't have to
launch all different applications again and again. It would be a big
breakthrough in Linux Audio imho. And then wait till an non-D-bus
solution appears, and see if that really works better...
Best wishes,
\r
The huge, major weak point that would prevent me
from investing myself
in LADI is the use of D-Bus which requires an extra, external layer in
order to perform routing between objects on different buses. See my
previous mail on the subject here:
http://lalists.stanford.edu/lad/2009/11/0350.html
D-Bus *can* span over multiple hosts. I've sent mail to this mailing
list that explains how to do it and what needs to be improved:
http://lalists.stanford.edu/lau/2009/11/0043.html
see also:
http://www.freedesktop.org/wiki/Software/DBusRemote (probably somewhat
obsolete, check the timestamp and the missing link to gabriel site).
I've adopted the gabriel project because it is possible to improve it as
a mean to achieve multihost LADI studios in future:
http://gabriel.sourceforge.net/
That said, there is no guarantee that ladish will use D-Bus for
communication between daemon and apps. LASH got this mainly because of
Juuso Alasuutari and because it was subject of his Summercode
project. My aim with "D-Bus + LASH" was to use D-Bus for lashd <-> jack
comunication and for lashd <-> control app communication. I agreed on
using D-Bus for app <-> lashd communication because that simplified
(yes it did) the LASH codebase. The use of D-Bus for app <-> ladishd IPC
was risky and it took some time to fix bugs, but at the end we made it
to work acceptably well.
Also, there is no guarantee that ladish will use D-Bus for remote IPC.
I have rough plan how to use D-Bus for multihost studios, but there is
lot of work to do until 1.0 is reached. After 1.0 is reached, I will
reconsider available options for the multihost capable ladish (that
will be 2.0), I will decide and I'll provide finer milestones to
acomplish this goal, in the same way as I did for 1.0.
In summary, I plan to use D-Bus at least until ladish-1.0 is
relased. I've seen lot of arguments against D-Bus and so far I din't
find them valid for the goals I'm working for. If D-Bus gets proven as
wrong choice for single hosts studio before the release of 1.0, I'll
have to change it early. However I find such incident highly
non-probable. Chances for remote D-Bus being not suitable are slightly
higher and I'll reconsider D-Bus after ladish-1.0 release. Until then,
D-Bus is the IPC technology that allows me to implement LADI features in
fastest possible way and does not look as something that I'll abandon
soon.
I'm always open for constructive discussions, especially if they are in
the scope of the LADI project. I'm open and glad for the feedback of
early jackdbus and ladish adopters.
From what Nedko has said on IRC, I believe LADISH
has such a layer.