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

6 Feb 2008

Bob Ham wrote:
...
  In case you missed this. 
Sorry that this took me so long!

...
  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.) 
What would guarantee that a JACK controller app would always get first 
priority (or be a "root dependency")? The controller app itself via an 
init flag? The user (bad idea IMHO)?

Anyway I'm not sure if this topic is going anywhere in the foreseeable 
future. I fully agree that priorities/dependencies is a good idea, though.

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

Another question is how needed/desired something like this actually is. 
(Does the VST SDK come with a HIG document?)

...
    >
		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. 
Otherwise I suggest you go ask about it on #debian. :)

...
   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 
All I have to say is good luck. :)

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

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

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

...
   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. 
That's as far as I'd be prepared to go. If LASH would notice that I 
didn't have $PROGRAM installed, and it would tell me my distro's package 
name for $PROGRAM, I'd be very happy. I would _possibly_ even be willing 
to click on a link saying, "Click here to install $PROGRAM using 
$YOUR_PACKAGE_MANAGER".

And even that "simple" feature would require LASH to ship with an 
up-to-date matrix of program names matched against all distros' 
corresponding package names...

...
   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. But I don't feel that we should really be wasting 
much time on this subject at this point anymore.

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

Juuso

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