5 Dec
2007
5 Dec
'07
12:36 p.m.
Lars Luthman wrote:
The difference is not in the number of lines but in
how many new
functions and types are used.
I think the cost-benefit ratio is important here. The added complexity
may be worth it for me, but perhaps not for you.
I hope we're still at pretty low complexity level, but that is a very
subjective thing.
If a plugin supports an event type (I assume
that's what you meant) it
can list it in its RDF file, and then the host can map it and that
plugin will get an ID for that event type URI,
The point is, how a previously loaded plugin (a transparent bridge or
something) will be informed about the new type? In most cases it would
work, though. It's just that "old" loaded plugins will not know the
mapping for "new" types, which might be OK for many applications. Not
that I think it's a good solution, just an acceptable one.
We can ignore the issue for now, but maybe it should be picked up later
at some point, when deciding about runtime extensibility.
Question to Dave, do you see any way to "invalidate" a particular RDF
triplet, then announce another one? say: PluginX is no longer a
ReverbPlugin, PluginX is now a FilterPlugin. Or port 4 is no longer the
plugin X's port. It's unrelated to our current discussion, I know.
Perhaps some kind of "rdf triplet" event type, that would carry
information about "knowledge update", if you know what I mean? Not
timestamped, perhaps :)
Sure. It's just on instantiation. If you wanted to
be smart you could
have the host sort the array and pass the size as well and let the
plugin do binary searches.
So it would have to be an array of pairs (uri, number), right? Because
otherwise adding any new number will mess up the numbering.
Krzysztof