Please keep Sebastien's emails in mind. Please don't throw all away all ideas from his work/email. The objective is to get everyone on the trunk. Let's try to find a way to get everyone to achieve their goals. We may not get there in the first release. But we should have a good story to go along with the release with end-to-end scenarios. Now, i'll shut up. It's upto you all to find the "Middle Way" literally.
thanks, dims [1] http://en.wikipedia.org/wiki/Middle_way On 3/27/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
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
-- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
