Re: [LAD] LADI

On Fri, Nov 20, 2009 at 10:15:20PM +0200, Nedko Arnaudov wrote:

<a lot, use your mail agent's facilities to read it>

Nedko,

Since you refer to me twice in your post I feel free to
respond. And even if you may regard me as one of your
'adversaries', please don't take anything I write as
a comment on you personally.

Let me say first that I'm sorry to see you in such a
state of despair. On one hand I'm sure you're not the
one to blame for it. On the other, you can't blame the
world. Some things are just what they are.

I do share many of your technical concerns about Jack,
about session management, and the state of LA in general.
My views on how they can be solved are probably quite
different to yours. This won't make me many friends, but
I don't believe there are easy solutions, in the sense
that there could be a gradual evolution, consisting of a
series of simple steps, each of them 'backwards compatible',
that would resolve the problems that do exist. Unless maybe
for someone who is prepared to wait much longer than I am.
This may be a personal attitude, but I believe that in a
situation like this one, at some point you have to bite
the bullet and clean up the mess that stands in the way,
no matter how much pain it causes. In IT language, some
of the solution (IMHO) will be incompatible with current
practices, APIs, and standards.

If I'd respond to all technical issues you raise the
result would be a 30-page paper. Maybe I should present
it a the next LAC, to be hung on the nearest high tree
shortly afterwards. So I'll limit my response to the
dbus related issues, also since you accuse me of having
waged a flame war against it.

Let me make it clear: I do not like dbus, for a variety
of reasons.

The first is its ugly API. That's opinion, but it's my
opinion and not likely to change any time soon.

The second, and more important, is that it mixes up a
lot of different things. Maybe, to arrive a Linux Audio
apps that are as user friendly as some of the ones that
exist on competing systems there are two solutions. One
is the 'integrated application' where everything can be
done within just one program, and the whole issue of
session management and connections is internal to that
application. The other is a degree of session management
that would provide almost the same user experience, and
for such a thing maybe a system like dbus is part of the
solution (but see comments below). But in that case the
only concern of such an inter-application communication
framework should be communication. Not security, access
control, or any form of policy. And certainly not any
dependency on irrelevant context, such as a desktop or
a local login.

** If you had proposed a separate 'audio dbus', completely
independent of the desktop session one, my reaction would
probably have been much more relaxed. **

The third, already hinted at above, is the close relation
of dbus to some other systems designed to provide a 'rich'
Windows-like desktop experience. The Kit family is not
really a set of independent and maybe on their own useful
components. It's rapidly becoming a 'all or nothing', take
it or leave it' sort of thing just like Windows, with all
the consequences that brings. And and least for me, those
consequences are not acceptable, the whole thing is much
too invasive and desktop-centered. And AFAICS, dbus is
very much married into that family.

Finally, some comments on session management.

If session management is supposed to work then apps have
to agree to being managed rather than doing everything
on their own. This includes for example external Jack
connections: to whom does a connection A->B belong, to
A or B ? At least Linux Audio's most famous app, Ardour,
is not moving that way - it's going the 'integrated app'
way, and even more so since its developers are looking
more and more towards OSX. Wait a bit more and it will
integrate everything you need to make (some types of)
music. And at that point the whole session management
issue will become irrelevant. Except for people like
me who are very much into minority interests that
never will be covered by integrated applications.

Secondly, being managed means that apps are talking to
their session manager. Not to each other. In other words,
this is a 'star' type of topology, not a bus. There are
many existing standard solutions for that, and they don't
need dbus. Nor do they need autolaunching of servers etc.

Ciao,

-- 
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev