26 Jan
2008
26 Jan
'08
6:39 p.m.
On Sat, 2008-01-26 at 22:25 +0200, Juuso Alasuutari wrote:
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.
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.
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.
Bob
--
Bob Ham <rah(a)bash.sh>
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.)
> 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. 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. 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
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.
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?
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.
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.
And I would
add to that now:
0.6
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).