On 8/16/06, Andrew Borley <[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. Sounds good - I'll work on the component language extension (< implementation.xxx>) side of things: 1) An SPI to allow Tuscany to invoke a method/function in the extension. Something like: void initialise(DataObjectPtr implXXXDO, map<string, string> initParameters); void invoke(Operation& operation); 2) An example wrapper that loads and runs a function in a Python module Cheers Andy
Don't you also need some way for the script engine, and particularly any extensions that have been written to get back to the SCA context information (i.e. the model) in the case the the script component makes subsequent calls to downstream components? Possibly part of the initialize although it looks like this is called on each invocation. Is that right? Don't we need some higher level initialization? S
