On Wed, 2008-02-06 at 16:05 +0200, Juuso Alasuutari wrote: > Bob Ham wrote: > > 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:
> >>>>> 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. > > I didn't realize you meant a recommendation and not some UI protocol. > (I'm not too familiar with GNOME.) Sure, but why should it be > LASH-centric? Why not write an official linuxaudio.org HIG? Indeed, why not? > Another question is how needed/desired something like this actually is. Looking at the massively disparate interfaces of the multitides of linux audio software, I'd say it's needed quite badly. > (Does the VST SDK come with a HIG document?) I assume not. Given that no two VST UIs seem to work the same way, it would appear not. > >>>>> 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. > > If we are to restrict this topic to strictly providing hooks for > existing package managers, then we might be able to stay out of trouble. I think we can stay out of trouble even by providing a package management system that isn't the disto's. > Otherwise I suggest you go ask about it on #debian. :) I'm asking you. > >> 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. > > The point isn't to safeguard the poor packagers from grey hair, although > to a certain extent that's also a factor. What I'm worried about is how > on earth will a rogue package manager, working irrespective of the > distro's own managing system, benefit the users in the long run? > Sure, you will be able to quickly install externally provided packages > via some nifty tool You answered your own question. > just like you can quickly unpack binary tarballs in > your root. And when the distro's package manager pulls a straw up its > nose due to broken lib dependencies and whatnot, I guess the users won't > feel too good afterall. You're assuming that a package management system that isn't the distro's would necessarily break the distro's package management system. That isn't the case. > >> If a session manager would take on package management like this -- which > >> it > >> definitely _shouldn't_ in the first place > > > > Why not? > > I apologize if this sounds like circular logic, but it is: A package > manager is what you use for managing packages, and when managing > packages what you should use is a package manager. Linux != Windows. I'm not proposing LASH become a package manager but that it uses a package manager. > >> -- 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? > > An external package installation system would by and far not work > "normally" at all on many systems. Sorry, the question was obviously ambiguous. By "normal" I meant that the automatic package installation feature would be disabled. > >> 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. > > I would strongly argue that managing packages is way beyond the concept > of session loading. Complete package management isn't within the concept of session loading, but package installation is. > >>>>> 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. > > Can you clarify whether you mean the LASH client or server interface > when you say that they would communicate similar information? I mean both. 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
