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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev