On 16/08/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 8/16/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > > > > > 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 Pete Not sure I've got the extent of what you are suggesting. So a couple of queations. You are suggesting 3 directories. 1/ Model schema 2/ Extensions, i.e. libraries implementing the extension scaffolding. 3/ Components that are implemented according to the extension (or do these just float around with the rest of the solution files) Can we also consider that the extension might be contributing to the model via annotations, over and above and information that is presented in XML side files. So in my case I might have a component defined with something like <implementation.php class="MyComponent" source="MyComponent.php"/> And I want the model to be completed based on the information in MyComponent.php rather than MyComponent.componentType. So can we have whatever the mechanism that loads componentTypes have a plug point into the extension system so that annotation info can be loaded. I'm keen on this because most developers in languages like Perl and PHP won't take too kindly to having to write XML side files. Regards Simon
Yes, dynamic addition of information to the model is necessary... but don't expect it in the first pass! ;-) -- Pete
