9 Feb
2008
9 Feb
'08
1:10 p.m.
On Wed, 2008-02-06 at 16:05 +0200, Juuso Alasuutari wrote:
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?
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.
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?
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.
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.
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.
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(a)bash.sh>
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. 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.
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. 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? -- 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? 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. >>
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.