On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea
grammostola wrote:
> 1) The 'one app with plugins' group. People who are focusing on
one big
> app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
> doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very
motivated to make them compatible with session handlers.
> 2) The people who likes to work with different, small Jack
applications
> (ams, aeolus, epichord etc.). These people are interested in a
session
> handler. But they think dbus is the wrong approach, it is to
limited for
> them, or it is not the right thing for the Linux platform in their
opinion.
'Like to work' may not be the correct interpretation. See (4)
> 3) Group 3 is the same as group 2, BUT they have chosen dbus as
> solution. It's the LADI group.
4. And there's group 4, or maybe that group is just me.
If there are others I'd like to know. For group 4:
* Sessions are multi-host since there is no other way.
In most cases all but one of the machines involved will
be headless, and whatever is supposed to happen there
is by definition remote controlled instead of being
launched from a local desktop.
* There are no usable 'single app with plugins' solutions
since none of these comes close to what would be required,
in particular w.r.t. the multi-host situation, and also
because all of these apps silently assume a human user
watching them and being able to take corrective action
if necessary. Anything that could pop up an error dialog
and refuse to proceed until someone reacts is completely
useless in such systems.
* Any interaction between components of such a system is
supposed to use networked communication from the start.
Dual-layer solutions based on some local IPC system plus
some additional layer that would connect them via a network
are just an unnecessary complication, and probably one that
would not provide the right semantics, since the design would
be based on the single host assumption in blissfull ignorance
of what it takes to make things work together via a network.
* Given the potential complexity of a networked system, loading
a 'session' would in general not mean a complete teardown and
buildup of all apps and their connections, but could just mean
loading a different configuration in a single app, without even
any others being aware of this.
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
Ciao,
--
FA