On Wed, 2006-04-26 at 01:23 +0200, Leonard "paniq" Ritter wrote:
On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard
wrote:
Plugins must be able to refuse hosts and hosts
must be able to refuse
plugins. It's the only way to allow extensions. I _guarantee_ plugins
will exist that some hosts just don't want (they already do with
LADSPA1), and some plugins will exists that require features hosts are
not required to provide. This is a Good Thing.
maybe in a Perfect World. in practice, we are going to face irritations
when plugins demand weird non-unified URIs to be passed in order to run
at all. from what i see, no new URIs can be invented without requiring
immediate support in all available hosts
Where did you get this crazy idea? The whole point is that different
hosts can provide different features.
and plugins that initially
only work for one host are not that cool. ergo, the "feature" of
blocking instantiation for a host not passing a required URI will be
rarely used, for the simple reason that it might not work with all
hosts. thus, do not allow it by spec.
You want to impose plugins work on the lowest common denominator of
hosts. Basically this amounts to mandating that certain plugins simply
can not exist. Why would you want to do that?
from my point of view, host features should be seen as
"hints", which
are not required, but of a suggestive nature.
Plugins are free to interpret them as such and not /require/ the
feature. It's totally up to the plugin.
my argumentation is chaotic. decipher the obvious!
While I am with you on the name thing, you don't understand. LADSPA2
will be completely installable in parallel with LADSPA1. Obviously it
will not "replace" LADSPA1 on a system and immediately break all the
installed plugins!
i hope this is taken care of! the new header suggests replacement, not
complementation.
The fact that you even considered that someone would really do this is
frightening. Not an issue ;)
This, like
most everything else, is in the data file. You really need
to read more than the header before commenting further ;)
the trusty header should be all documentation required... there was also
no reference to additional documents in it. how about adding it? :o)
If you think the header should be all the documentation required, then
you completely Don't Get It on a fundamental level. Read the example
plugin - all of it.
-DR-