I don't see any of the following terms in those emails...Let me take another tack
"I think there is room for a reorganization there to clarify the usage of those interfaces.". Can you please send a write up in wiki on how to do the reorganization. You can either augment/enhance what Raymond wrote or start fresh. thanks, dims On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
http://www.mail-archive.com/[email protected]/msg15978.html http://www.mail-archive.com/[email protected]/msg15991.html r522186 r521957 http://www.mail-archive.com/[email protected]/msg15318.html in relation to r517804 And, of course, the code in SVN. Lastly, we've been here before - r419320 -- Jeremy On Mar 27, 2007, at 2:35 PM, Davanum Srinivas wrote: > "the wholesale, revolutionary rewrite of the kernel"...Pointers please > to exact emails. > > thanks, > dims > > On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> Nice diagram, Raymond, thanks for putting this together. >> >> What I'm struggling with is that this seems fairly similar to the way >> the code is organized now. Most of the boxes there already exist and >> have interfaces to abstract away their implementation. Everything in >> "Cross-cutting system services" is that way and the same for >> "Container/Binding/Databinding/IDL Extensions" and "Pluggable >> Federations." >> >> These are all components implemented using the Tuscany "system" >> programming model - basically, a simplified, POJO based IoC model >> decorated (to the least extent possible) with SCA annotations. Each >> of those components already has an interface to define the function >> it provides. >> >> We assemble those components using SCA assembly. That makes sense to >> me because as an SCA runtime we have to support SCA assembly - so not >> only will we need the code to do that, it makes things familiar to >> users as there is a common language. We could assemble the runtime >> another way, for example using Spring XML or Java code, but then >> users need to be familiar with two assembly mechanisms and that seems >> like confusing and unnecessary complexity. >> >> One reason the SPI module is so large is that it does define many the >> interfaces for the components in you diagram. I think there is room >> for a reorganization there to clarify the usage of those interfaces. >> I would propose we start with that rather than the wholesale, >> revolutionary rewrite of the kernel that has been suggested. >> >> -- >> Jeremy >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services > Developers > > --------------------------------------------------------------------- > 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]
-- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
