6 Nov
2009
6 Nov
'09
1:31 p.m.
On Fri, Nov 06, 2009 at 10:55:17AM -0500, David Robillard wrote:
Doesn't it ? If a host has to consider all active
extensions as a whole then the number of possible
combinations explodes. If it considers them one by
one, doing what is required for extension A could
easily have an impact on extension B, if both are
about similer things, e.g. ports. For this reason
a host author could decide to do first B then A, if
that solves his problem. At the same time a plugin
author could assume (even without been aware of
this) that the order has to be A then B.
Prove it.
Right.
I don't hate it. I just remember the complete chaos that
resulted from uncoordinated ad-hoc extensions to HTML, before
the mess was more or less cleaned up.
I'd rather not. And this has nothing to do with ease of
development, or overhead in the sense that I takes more
of my time. My opinion would not change even if a perfect
SDK would hide all the dirty details and overhead.
The final result is what should be no be more complex
than required.
I wouldn't require them otherwise.
How could changing the rules about how anything
references ports be done
as an extension?
By doing it the new way if the extension is requested,
and the old way otherwise.
... What extensions are in conflict? FUD FUD FUD
Can you name two LAD members with the same birthday ?
Probably not, but if you put 23 of them in a room the
chances are 50% there will be two. At the moment there
are few extensions, so probably there's no conflict.
Or depend on
things that are specified nowhere, such
as the order in which a host should use them and call any new
extension specific functions in the plugin ?
This doesn't really make any sense. What mechanism
is
there in LV2's core spec that ensures that extensions will be
orthogonal to each other, even if written by authors who don't
know each other's work, and evaluated by a host in unspecified
order ?
This also makes no sense. It might be possible to deliberately
construct a really, really, really cracked out extension that would
somehow be in "conflict" with another, but I can't even come up with
such a case. I'd say the chance of this happening with extensions that
aren't deliberately written to do this is extremely close to 0. Even in
this overwhelmingly unlikely case, if conflicting extensions existed it
simply would not make sense to implement them both in a single plugin.
The whole idea of a plugin system is that host and plugins can be
developed separately. This requires that all parts of the API,
*including their possible interactions and dependencies* are
either well-defined, or guaranteed by design not to interfere
with each other.
I'm not
going to spend even a minute writing a plugin or
a set of them, requiring maybe five new extensions, if I'm
not absolutely sure that these extensions will be accepted
(that is: implemented) by the authors of the major host
programs, e.g. Ardour. And don't ask me to do that myself.
It would take ages for me to get familiar enough with e.g.
Ardour's internal structures and code to be able to do that.
And even then, the patches would still have to be accepted
by Ardour's core team. And that's only _one_ host, be it an
important one.
Fine then, don't. Nobody says you have to do anything.
That's valid for anything in FOSS. Still I'm doing things.
You not wanting to do stuff is certainly is not an
argument
against LV2.
Having one potential plugin author less means a (small) impact
on its acceptance. It's not a technical argument, that's true.
...
Should I try and use LV2 for all of this ?
Lucky for you, because of the extension mechanism you ironically
seem to hate, you can :) It would
create
a lot of extra complexity, starting with having to squeeze
everything through a C interface while both sides are C++,
(see below)
a lot of textual representation of fixed things
just adding
overhead
This is true, but the benefits are substantial, it's not "just" adding
overhead. Extensions could be invented to avoid (most of) the text part
entirely, but that's a lot of work for little gain. I'd rather just
deal with that overhead as it comes up. , and a
collection of extensions that I'm pretty
sure no other host will ever implement.
What would these extensions be? And would they be mandatory for the
plugins working whatsoever? You can use C++ in an extension if you like. Such an
extension would be
trivial, e.g. "the extension_data method on a plugin, called with this
URI, returns an object of this type".
The extreme case of this is what I proposed in my Q2 earlier.
That object could take over the complete API, and in many
cases that would be the simplest solution.
Might piss off some of the pure C
people, but whatever. It's better to have LV2 plugins that (can) work
in any C++ host than no plugins that work elsewhere at all.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.