25 Apr
2006
25 Apr
'06
9:15 p.m.
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, 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.
from my point of view, host features should be seen as "hints", which
are not required, but of a suggestive nature.
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.
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)
-DR-
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org