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.