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.)
> > > > 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.
> > > > 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.
> 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).
> >
> > 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@email-addr-hidden>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
This archive was generated by hypermail 2.1.8 : Sun Jan 27 2008 - 04:15:02 EET