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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Feb 6 16:15:03 2008
This archive was generated by hypermail 2.1.8 : Wed Feb 06 2008 - 16:15:03 EET