> This looks like a really good plan. I have two questions: > > 1. Do we really need another XML file to describe the extension, name > the library and associate it with an implementation type? As a first > step at least, I think it would be great to have a very simple scheme > where you just drop a library named implementation.python in a Tuscany > extensions or plugins directory, or just name the library how you want > but have in it an extern public functtion that will return the XSD > QNames that the library understands? Yeah, I was thinking a "drop it in a directory" approach would be good, but I couldn't think how to expose the information we need - specifically naming the library/xsd file and/or having a set of known public functions is a good way to go. I will do this first - possibly an xml config file would also be useful - we should be able to support both?
Sebastien's suggestion is how I would do it. What we need is to define an extensions spi. We need a directory that contains the schema for the exensions. We will load all of these so the model loader can parse all the scdl into SDO. We need an extensions directory where we will load any library that is in it. We then call the spi function which will return a list of XSD QNames supported by the extension. When the model loader encounters an extension it passes the SDO to a method in the extension library to deal with. I'm about to hack about, I mean tidy up, the model loader code so I'd like to take on this part of the extesnion story if that's ok with everyone? I'll come up with a suggested SPI. Cheers, -- Pete
