[LAD] [Fwd: Re: Summercode 2008: LASH as a D-Bus service]

[Bob Ham]

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 at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080209/bbe31c90/attachment.pgp>