7 Nov
2009
7 Nov
'09
1:52 p.m.
On Fri, 2009-11-06 at 18:27 +0100, fons(a)kokkinizita.net wrote:
This presumes that extensions "conflicting" makes sense, or is likely to
happen.
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
Why? Says who? Example?
Prove it.
Extensions are usually either new port types, which can't conflict with
anything, or newly added functions, which can't conflict with anything
either.
The only kind of extension that could "conflict" is what that redefines
the semantics of something very fundamental in the core spec, which is
silly, and again, even if such an extension existed, it doesn't matter,
because that one particular weird extension might not make sense with
such and such a host/plugins/extension/whatever. So? If it's
fundamentally incapable of working in some setup, then it won't.
You are making the outrageous claim, the burden of proof is on you.
Again, what interactions and dependencies? You're waving your hands
around screaming about "conflict" with no example or argument to suggest
such conflict is likely or even possible.
Is isn't, and furthermore, if it did happen it's not a big dealer, and
furtherfurthermore, the community would take care of this anyway (why
would anyone do this without a good reason? and if they did, why would
anyone implement it?)
Here is an actual example of the sort of way extensions might
"conflict": Extension A says the block size passed to the process method
must be always 1. Extension B says the block size passed to the process
method must be always 512. These extensions "conflict". So what? You
can't do both on the same plugin, obviously. The things they describe
inherently "conflict". This is simply not a problem.
If you think it is a problem, then come up with an example for why. I
can't think of one.
Maybe, and everyone would like as many plugins as possible, but you
don't have any concrete reasons. I'd love to address your concerns, but
you don't have any actual concerns. One can not make a patch for FUD.
Why should you even care if this "conflicting" thing is possible anyway?
Will it affect your plugins? Obviously not, you couldn't implement
"conflicting" extensions on a single set of plugins anyway, by
definition.
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.
A better analogy would be well-formed XML or RDF, where things can
easily be added but it doesn't break anything because the technology has
been designed specifically to handle this; or my shared library analogy
from earlier.
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.
Having the data separate from the code is pretty much "required" to get
all the things we want anyway. Is it more complex than is "required"?
Maybe. It depends how you feel like conveniently defining "complex".
Having an equivalently powerful data model defined in the code somehow
is hardly free either. A vague notion of "complex" doesn't really
matter much when there are tangible advantages/disadvantages to take
into consideration.
I wouldn't require them otherwise.
A lot of functionality can be implemented such that the plugin works
without it. You don't /have/ to "require" them.
This wouldn't be an LV2 plugin at all.
-dr
On Fri, Nov 06, 2009 at 10:55:17AM -0500, David
Robillard wrote:
This would not solve the problem because hosts need to follow the rules
too. The core spec obviously has to specify things like how to refer to
ports correctly. There are a small number of things that need to be
defined in the core spec for obvious reasons, this is one of them.
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. , 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.
I don't know what this "order" stuff means at all. Extensions don't
have an order.
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. 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 :) 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.