Re: SPI modularity
On Jul 1, 2006, at 9:28 AM, Jeremy Boynes wrote: On 7/1/06, Jim Marino [EMAIL PROTECTED] wrote: I believe a good portion of that 300K is related to the Geronimo WorkManager dependencies. Since WorkManager can be implemented as a thin facade over the JDK 5 concurrency libraries, we should look at implementing a simple one and eliminating the dependencies. Once we do that, I think we will only need StAX, which is slated to become part of the JDK anyway. The 300K was the size of the two Tuscany jars - I didn't factor in the size of dependencies. Hmm tI guess that is even more reason to limit external dependencies :-) I agree we should have another look at using Geronimo's implementation. I know it was my suggestion to use it but it pulls in quite a bit given what it does vs. what's in the JRE. What does annotation do? On a related note, I think we also have a POJO extension model for things like annotation processors. I don't think this can be easily factored into an SPI below core since it will drag in a whole bunch of things (either in the basic SPI package or a special POJO SPI package). Any ideas would be great...otherwise we may just say that type of extension is a low- level one done off core. I was thinking the annotation processing stuff would end up there and that would be part of deployment. Thinking more we would want the annotations used by components to decorate themselves to be some API package. Yea we may be able to that but it -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SPI modularity
Jean-Sebastien Delfino wrote: - Modularity, building our runtime in a more modular way, with more but simpler modules, clean SPI modules with only interfaces, and decoupling the core and the Java component implementation type / container. - Simpler SPIs, covering all aspects of the cycle (development, build, deployment + install, runtime, admin etc.) There's several things here conflated together - I propose we tackle them separately. If you define runtime as a running SCA environment, I think we have a good start on a modular approach. There are bound to be tweaks but I think we are going in the right direction. We have a basic core with a well-defined SPI into which we can add extensions without needing any change to the core. We also have ways in which extensions can co-operate, providing new extension points themselves into which other things can plug. spi and core2 combined are about 12000 lines of code and the binary is just over 300K in size - this is not very big really. Having said that, I agree that we can restructure the SPI module to make things a little clearer. I think some of the confusion now comes because it contains both runtime and deployment interfaces. We agreed a long time ago that we wanted the runtime to be self-contained and independent of the deployment mechanism used. Bearing that in mind, we should be able to separate the runtime part of the SPI from the deployment part. Taking a quick swag at the top-level packages in the SPI I would propose we create two new ones, deployment and runtime, and move things around as follows: runtime: bootstrap, component, event, host, monitor, policy, services, wire deployment: annotation, builder, deployer, loader, model Assuming this works and all dependencies point from deployment to runtime we could then split the SPI module into two. I'd like to re-evaluate before doing that though as I think a typical usage would always have both runtime and deployment code and would typically always need both modules. Making people deal with two things just seems like unneeded complexity. Finally, I think we need to be clear about what is an SPI and what is an API. To me, an SPI is something used by an system to expand its functionality, it's a view from the inside looking out; an API is used by something else to manipulate a system, it's a view from the outside looking in. With that in mind I think some of the SPIs you mention above are really APIs. Things like deployment, install, admin (and I'd add management, monitoring) are interfaces the runtime would provide to allow outside entities to manipulate it. I'd propose that this may be a better way to slice up the current spi module. For example, we could consider splitting out the bootstrap and deployer packages into a new api module. The intention would be to provide interfaces used by external actors without exposing them to the mechanisms used to extend the runtime. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SPI modularity
On Jul 1, 2006, at 2:42 AM, Jeremy Boynes wrote: Jean-Sebastien Delfino wrote: - Modularity, building our runtime in a more modular way, with more but simpler modules, clean SPI modules with only interfaces, and decoupling the core and the Java component implementation type / container. - Simpler SPIs, covering all aspects of the cycle (development, build, deployment + install, runtime, admin etc.) There's several things here conflated together - I propose we tackle them separately. If you define runtime as a running SCA environment, I think we have a good start on a modular approach. There are bound to be tweaks but I think we are going in the right direction. We have a basic core with a well-defined SPI into which we can add extensions without needing any change to the core. We also have ways in which extensions can co-operate, providing new extension points themselves into which other things can plug. spi and core2 combined are about 12000 lines of code and the binary is just over 300K in size - this is not very big really. I believe a good portion of that 300K is related to the Geronimo WorkManager dependencies. Since WorkManager can be implemented as a thin facade over the JDK 5 concurrency libraries, we should look at implementing a simple one and eliminating the dependencies. Once we do that, I think we will only need StAX, which is slated to become part of the JDK anyway. Having said that, I agree that we can restructure the SPI module to make things a little clearer. I think some of the confusion now comes because it contains both runtime and deployment interfaces. We agreed a long time ago that we wanted the runtime to be self-contained and independent of the deployment mechanism used. Bearing that in mind, we should be able to separate the runtime part of the SPI from the deployment part. Taking a quick swag at the top-level packages in the SPI I would propose we create two new ones, deployment and runtime, and move things around as follows: runtime: bootstrap, component, event, host, monitor, policy, services, wire deployment: annotation, builder, deployer, loader, model What does annotation do? On a related note, I think we also have a POJO extension model for things like annotation processors. I don't think this can be easily factored into an SPI below core since it will drag in a whole bunch of things (either in the basic SPI package or a special POJO SPI package). Any ideas would be great...otherwise we may just say that type of extension is a low- level one done off core. Assuming this works and all dependencies point from deployment to runtime we could then split the SPI module into two. I'd like to re-evaluate before doing that though as I think a typical usage would always have both runtime and deployment code and would typically always need both modules. I don't see separating these into two projects is worth the added complexity. As long as we have a clear packaging structure, IMO it is much easier to deal with one extension jar. Making people deal with two things just seems like unneeded complexity. Finally, I think we need to be clear about what is an SPI and what is an API. To me, an SPI is something used by an system to expand its functionality, it's a view from the inside looking out; an API is used by something else to manipulate a system, it's a view from the outside looking in. With that in mind I think some of the SPIs you mention above are really APIs. Things like deployment, install, admin (and I'd add management, monitoring) are interfaces the runtime would provide to allow outside entities to manipulate it. This is a god point. I think it also entails a different design approach. For example, an SPI is intended for experienced, systems- level programmers and therefore can sacrifice a bit of complexity for power and flexibility. I'd propose that this may be a better way to slice up the current spi module. For example, we could consider splitting out the bootstrap and deployer packages into a new api module. The intention would be to provide interfaces used by external actors without exposing them to the mechanisms used to extend the runtime. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SPI modularity
On 7/1/06, Jim Marino [EMAIL PROTECTED] wrote: I believe a good portion of that 300K is related to the Geronimo WorkManager dependencies. Since WorkManager can be implemented as a thin facade over the JDK 5 concurrency libraries, we should look at implementing a simple one and eliminating the dependencies. Once we do that, I think we will only need StAX, which is slated to become part of the JDK anyway. The 300K was the size of the two Tuscany jars - I didn't factor in the size of dependencies. I agree we should have another look at using Geronimo's implementation. I know it was my suggestion to use it but it pulls in quite a bit given what it does vs. what's in the JRE. What does annotation do? On a related note, I think we also have a POJO extension model for things like annotation processors. I don't think this can be easily factored into an SPI below core since it will drag in a whole bunch of things (either in the basic SPI package or a special POJO SPI package). Any ideas would be great...otherwise we may just say that type of extension is a low- level one done off core. I was thinking the annotation processing stuff would end up there and that would be part of deployment. Thinking more we would want the annotations used by components to decorate themselves to be some API package. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
