On Sat, 2008-01-26 at 22:25 +0200, Juuso Alasuutari wrote: > On Friday 25 January 2008 18:27:10 Bob Ham wrote: > > On Fri, 2008-01-25 at 14:04 +0200, Juuso Alasuutari wrote: > > > On Wednesday 23 January 2008 23:21:21 Bob Ham wrote:
> And I can imagine how the session loading could happen approximately like > this: > - LASH launches the JACK controller app, > - the JACK controller app modifies JACK settings and possibly restarts JACK > if > necessary, > - LASH launches the rest of the clients, > - LASH connects the ports between the clients. > Now imagine the above scenario, but imagine that the JACK controller app > doesn't get launched first. It will potentially wreck the session if it > restarts JACK after other clients have loaded. If controlling JACK settings > is done by one of the session clients, should that client be able to register > to LASH with a special flag which indicates that it should launch first? This would be dealt with by client priorities (or dependencies.) > > > > User interface standard > > > > Promote a standard to LASH clients in order to present a consistent user > > interface. This would be like the GNOME HIG but audio-specific, eg, > > specifying knob widget appearance and behaviour, recommending audio > > widget toolkits, etc. > > You're treading on flammable ground here. I wouldn't want LASH to have the > slightest authority over what toolkits and/or widgets the clients are coded > with. And I don't see any reason why LASH should even care; LASH isn't a > plugin host. I should be able to include an Ncurses-based drum machine with > my session if I please. The GNOME HIG isn't enforced. Nor, I believe, is there any way to enforce it. It's simply a document to communicate to developers of GNOME applications the expectations that any application has on it when taking part in a GNOME desktop. Similarly, the user interface standard for LASH would simply be a document to communicate to developers of LASH clients the expectations, in terms of user interface harmony, that any client has on it when taking part in a LASH session. > > > > Automatic client installation > > > > > > This sounds an awful lot like stepping on the toes of packagers and > > > package managers. Unless you mean something completely different, of > > > course. > > > > What's meant is: if you load a session and it includes a client that > > isn't installed on the system, then make it such that it is installed > > and the session can be loaded. This is no small thing. There are a few > > options: > > > > 1. Create a system which abstracts package management for different > > distros > > 2. Try and create an automatic compilation environment, similar to > > ports on Freebsd or portage on Gentoo (lol) > > 3. Use autopackage > > > > From the client side, this would be very simple: the programmer just > > provides a URL to some meta-information that describes the packages > > needed for that LASH client. I think this is pretty doable now that > > number 3 exists. > > Yes, you are stepping on packagers' toes here -- heavily. Why do you think packagers' toes are being stepped on? I can't see any conflict between package developers and a LASH package installer. > Abstracting package management for distros is an insanely huge task Note the phrase "this is no small thing" above. > , and not > likely to work in practice. Possibly > Creating an automatic compilation environment -- > well, I assume you're joking Nope > because this would equal writing your own > source-based package manager Yep > Using autopackage is out of the question, > because you simply can't fulfill the needs of all distros Autopackage exists. It works. It doesn't seem to be out of the question. The issue isn't fulfilling the needs of the distro but fulfilling the needs of the user. > If a session manager would take on package management like this -- which it > definitely _shouldn't_ in the first place Why not? > -- it would have to work absolutely > _perfectly_ on _all_ possible distros. Either that, or nothing. Why would reverting to normal, not-as-astonishingly-cool behaviour on some distros be bad? > I wouldn't want autopackage messing around with my box -- I want > packages installed the way they normally are with Source Mage. Then don't use the automatic LASH client installer :-) Or you could implement the distro-specific functionality for your distro. That would allow you to have your packages installed the way they normally are with Source Mage. > Considering how you've been defending LASH from features that you deem > outside > of its domain, I'm surprised that you would come up with this idea. Session loading is within the domain of LASH. > > > > And I would add to that now: > > > > > > > > 0.6 > > > > Redesign client/server communication > > > > Certificate based security/encryption > > > > > > Why would managing an audio session demand that the connections be > > > certified and encrypted? Unless you're thinking network-wise (i.e. > > > sessions that span several networked computers). > > > > I'm thinking network-wise. > > As I've said before, I don't believe it's a good idea to add this stuff to > the > client protocol. Inter-host communication is a different thing. There's an assumption here that lashd<->lashd and lashd<->client protocols aren't the same thing. They would be communicating very similar information. Having two protocols would be unwieldy. Bob -- Bob Ham <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
