linuxaudio.org

--=-ca7zxhYXK4C3DAX1xtp5

Content-Type: text/plain

Content-Transfer-Encoding: quoted-printable
On Wed, 2008-02-06 at 16:05 +0200, Juuso Alasuutari wrote:

quoted text
> 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

quoted text
> >>> Promote a standard to LASH clients in order to present a consistent u=

ser

quoted text
> >>> 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=20

quoted text
> >> slightest authority over what toolkits and/or widgets the clients are =

coded=20

quoted text
> >> with. And I don't see any reason why LASH should even care; LASH isn't=

 a=20

quoted text
> >> plugin host. I should be able to include an Ncurses-based drum machine=

 with=20

quoted text
> >> my session if I please.

> >=20

> > 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.

> >=20

> > 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.

>=20

> I didn't realize you meant a recommendation and not some UI protocol.=20

> (I'm not too familiar with GNOME.) Sure, but why should it be=20

> LASH-centric? Why not write an official linuxaudio.org HIG?

Indeed, why not?
> Another question is how needed/desired something like this actually is.=20
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

quoted text
> >>>> 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

quoted text
> >>> options:

> >>>

> >>>      1. Create a system which abstracts package management for differ=

ent

quoted text
> >>>         distros

> >>>      2. Try and create an automatic compilation environment, similar =

to

quoted text
> >>>         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.

> >=20

> > Why do you think packagers' toes are being stepped on?  I can't see any

> > conflict between package developers and a LASH package installer.

>=20

> If we are to restrict this topic to strictly providing hooks for=20

> existing package managers, then we might be able to stay out of trouble.=20

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,=20

quoted text
> >> because you simply can't fulfill the needs of all distros

> >=20

> > 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.

>=20

> The point isn't to safeguard the poor packagers from grey hair, although=20

> to a certain extent that's also a factor. What I'm worried about is how=20

> on earth will a rogue package manager, working irrespective of the=20

> distro's own managing system, benefit the users in the long run?

> Sure, you will be able to quickly install externally provided packages=20

quoted text
> via some nifty tool

You answered your own question.
> just like you can quickly unpack binary tarballs in=20

quoted text
> your root. And when the distro's package manager pulls a straw up its=20

> nose due to broken lib dependencies and whatnot, I guess the users won't=20

> 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 -- whi=

ch it=20

quoted text
> >> definitely _shouldn't_ in the first place

> >=20

> > Why not?

>=20

> I apologize if this sounds like circular logic, but it is: A package=20

> manager is what you use for managing packages, and when managing=20

> packages what you should use is a package manager. Linux !=3D Windows.

I'm not proposing LASH become a package manager but that it uses a

package manager.
> >> -- it would have to work absolutely=20

quoted text
> >> _perfectly_ on _all_ possible distros. Either that, or nothing.

> >=20

> > Why would reverting to normal, not-as-astonishingly-cool behaviour on

> > some distros be bad?

>=20

> An external package installation system would by and far not work=20

> "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=20

quoted text
> >> of its domain, I'm surprised that you would come up with this idea.

> >=20

> > Session loading is within the domain of LASH.

>=20

> I would strongly argue that managing packages is way beyond the concept=20

> of session loading.

Complete package management isn't within the concept of session loading,

but package installation is.
> >>>>> 		Redesign client/server communication

quoted text
> >>>>> 			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 stuf=

f to the=20

quoted text
> >> client protocol. Inter-host communication is a different thing.

> >=20

> > 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.

>=20

> Can you clarify whether you mean the LASH client or server interface=20

> when you say that they would communicate similar information?

I mean both.
Bob
--=20

Bob Ham 
--=-ca7zxhYXK4C3DAX1xtp5

Content-Type: application/pgp-signature; name=signature.asc

Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBHrd5u7whsMRnFexQRAtsTAKCYlCs/vTDl2ZmHISivXXNq9ehwtACfXEOP

0UAXyzNxDvkhfym+K3mmrAU=

=astZ

-----END PGP SIGNATURE-----
--=-ca7zxhYXK4C3DAX1xtp5--