Re: Creating multiple / smaller SPI projects
On Jun 26, 2006, at 4:20 PM, Jeremy Boynes wrote: On 6/26/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Here are a few thoughts and questions on our SPI story. I'd like to start a discussion on these items and get your thoughts. Cool. My first thought is that what you're describing here is very close to what we have in the sandbox - for example, common themes of modularity and removing complexity. I've added a few more detailed comments inline. We also tried to do this in terms of separating out various runtime capabilities as well. For example, Raymond's databinding approach could be a system service that is plugged into the core. The idea is the core performs a very limited set of specific tasks and the rest are delegated to extensions. Right now we have around 8,500+ lines of code in core. It would be great if we could limit it to say (arbitrarily) 25,000 lines max. A. I think we should create different projects for the various types of SPI we have, for example one project for the assembly model SPI, one project for the interaction/invocation related SPI, one project for the deployment SPI, one for the management SPI etc. This sounds good, especially when we deal with high level building blocks like management. One thing I think we need to be careful of though is breaking it down too far so that we force users to understand several different modules just to do something simple. I think we can address that with the right package structure in each module. One thing is we may be able to change the SPI packages around to improve clarity but I agree we have to pick the right level of granularity for our project structure. If these SPI go into a spec at some point this will allow us to publish them and evolve them independently. Agreed. We are actually leading the spec here which gives us a chance to influence the direction it is taking. However, when the spec actually adopts something the classes will move from the o.a.t namespace to the org.osoa one which will impact users and implementations. We can handle those changes for both separate modules and individual packages within a module. I also think that this allows to cut complexity, for example a contributor only interested in management will not get the other SPIs. More generally, somebody assembling/embedding a Tuscany runtime will be in a better position to pick a subset of selected pieces. Cutting complexity is good and we can help with that by making sure that things that naturally go together are bundled together. For example, someone writing an extension should not need to dig through several modules to figure out what they need to do. Finally this shows a clear path to people who want to extend the runtime, for example, if we put the java interface support in a different project, the WSDL interface support in another one, then somebody wanting to add ruby or javascript support will have a clear template to follow. I'm not sure what you mean here. This sounds like two implementations of a pluggable interface type SPI - one for Java interfaces, one for WSDL ones - which I think would be a good way to break this down. B. I'd like to separate interfaces and implementation classes or helpers in different projects. Wholeheartedly agree on the separation between interface and implementation. In M1 we did this but had both inside the same module which was confusing; one of the things we did in the sandbox was to move the interfaces into spi and leave the implementation in core. I think helpers can go either way. If they are useful (but optional) to any implementation of the interface, then we can reduce the complexity by including them with the SPI. An example of this would be the extension base classes that contain functionality to support an implementation but which (in general) don't implement the interface contracts. On the other hand, classes that support a specific implementation should just be part of it (directly or in the form of a library). For example the assembly model interfaces would go into one project, the Tuscany implementation of these interfaces in a different one. In M1 we have interfaces+implementation classes but they are in the same project, in the sandbox there's no interfaces anymore for this, can you guys tell me what motivated that change? Simplicity really. The model objects are really just data holders (set and get methods only) and don't contain significant implementation. Separate interfaces and implementation classes will allow us to swap different implementations (e.g. using different databindings, or integrated with tooling for example). It will also allow model extensions to not depend on Tuscany implementations classes (the extensions will only implement interfaces instead of extending implementation classes). C. I would like to change the project folder structure a little and introduce a plugins/ directory where contributors could
Creating multiple / smaller SPI projects
Here are a few thoughts and questions on our SPI story. I'd like to start a discussion on these items and get your thoughts. A. I think we should create different projects for the various types of SPI we have, for example one project for the assembly model SPI, one project for the interaction/invocation related SPI, one project for the deployment SPI, one for the management SPI etc. If these SPI go into a spec at some point this will allow us to publish them and evolve them independently. I also think that this allows to cut complexity, for example a contributor only interested in management will not get the other SPIs. More generally, somebody assembling/embedding a Tuscany runtime will be in a better position to pick a subset of selected pieces. Finally this shows a clear path to people who want to extend the runtime, for example, if we put the java interface support in a different project, the WSDL interface support in another one, then somebody wanting to add ruby or javascript support will have a clear template to follow. B. I'd like to separate interfaces and implementation classes or helpers in different projects. For example the assembly model interfaces would go into one project, the Tuscany implementation of these interfaces in a different one. In M1 we have interfaces+implementation classes but they are in the same project, in the sandbox there's no interfaces anymore for this, can you guys tell me what motivated that change? Separate interfaces and implementation classes will allow us to swap different implementations (e.g. using different databindings, or integrated with tooling for example). It will also allow model extensions to not depend on Tuscany implementations classes (the extensions will only implement interfaces instead of extending implementation classes). C. I would like to change the project folder structure a little and introduce a plugins/ directory where contributors could drop their extension projects/modules. It is not clear to me anymore that we need different bindings/ and containers/ folders. I'm thinking more and more that the programming model for component implementation extensions and binding extensions should be the same. Some plugins will not be implementation or binding specific, for example it should be possible to contribute a plugin that provides support for a new interface definition language. Also these plugins will have to contribute multiple extensions covering codegen/development, model, validation, deployment, install, invocation, management etc. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating multiple / smaller SPI projects
On 6/26/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Here are a few thoughts and questions on our SPI story. I'd like to start a discussion on these items and get your thoughts. Cool. My first thought is that what you're describing here is very close to what we have in the sandbox - for example, common themes of modularity and removing complexity. I've added a few more detailed comments inline. A. I think we should create different projects for the various types of SPI we have, for example one project for the assembly model SPI, one project for the interaction/invocation related SPI, one project for the deployment SPI, one for the management SPI etc. This sounds good, especially when we deal with high level building blocks like management. One thing I think we need to be careful of though is breaking it down too far so that we force users to understand several different modules just to do something simple. I think we can address that with the right package structure in each module. If these SPI go into a spec at some point this will allow us to publish them and evolve them independently. Agreed. We are actually leading the spec here which gives us a chance to influence the direction it is taking. However, when the spec actually adopts something the classes will move from the o.a.t namespace to the org.osoa one which will impact users and implementations. We can handle those changes for both separate modules and individual packages within a module. I also think that this allows to cut complexity, for example a contributor only interested in management will not get the other SPIs. More generally, somebody assembling/embedding a Tuscany runtime will be in a better position to pick a subset of selected pieces. Cutting complexity is good and we can help with that by making sure that things that naturally go together are bundled together. For example, someone writing an extension should not need to dig through several modules to figure out what they need to do. Finally this shows a clear path to people who want to extend the runtime, for example, if we put the java interface support in a different project, the WSDL interface support in another one, then somebody wanting to add ruby or javascript support will have a clear template to follow. I'm not sure what you mean here. This sounds like two implementations of a pluggable interface type SPI - one for Java interfaces, one for WSDL ones - which I think would be a good way to break this down. B. I'd like to separate interfaces and implementation classes or helpers in different projects. Wholeheartedly agree on the separation between interface and implementation. In M1 we did this but had both inside the same module which was confusing; one of the things we did in the sandbox was to move the interfaces into spi and leave the implementation in core. I think helpers can go either way. If they are useful (but optional) to any implementation of the interface, then we can reduce the complexity by including them with the SPI. An example of this would be the extension base classes that contain functionality to support an implementation but which (in general) don't implement the interface contracts. On the other hand, classes that support a specific implementation should just be part of it (directly or in the form of a library). For example the assembly model interfaces would go into one project, the Tuscany implementation of these interfaces in a different one. In M1 we have interfaces+implementation classes but they are in the same project, in the sandbox there's no interfaces anymore for this, can you guys tell me what motivated that change? Simplicity really. The model objects are really just data holders (set and get methods only) and don't contain significant implementation. Separate interfaces and implementation classes will allow us to swap different implementations (e.g. using different databindings, or integrated with tooling for example). It will also allow model extensions to not depend on Tuscany implementations classes (the extensions will only implement interfaces instead of extending implementation classes). C. I would like to change the project folder structure a little and introduce a plugins/ directory where contributors could drop their extension projects/modules. It is not clear to me anymore that we need different bindings/ and containers/ folders. I'm thinking more and more that the programming model for component implementation extensions and binding extensions should be the same. Some plugins will not be implementation or binding specific, for example it should be possible to contribute a plugin that provides support for a new interface definition language. Also these plugins will have to contribute multiple extensions covering codegen/development, model, validation, deployment, install, invocation, management etc. I think we're heading the same way here. To me, containers and bindings were just a
