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 <rah@email-addr-hidden>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
This archive was generated by hypermail 2.1.8 : Sat Feb 09 2008 - 20:15:02 EET