You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/06/05 19:03:51 UTC
Re: Recursive core architectural overview
Jim Marino wrote:
> Hi,
>
> There has been some mention offline of Jeremy and I providing an
> overview of changes to the SCA specifications and related recursive
> core architecture work going on in the sandbox, perhaps Wednesday. I'm
> happy to do this, however, I'm a bit concerned that since this has not
> been brought up on the list interested people may not be able to attend
> on short notice. Also, a time has not been mentioned. I propose
> 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which
> will be provided later.
>
> If interested people cannot make that time, please speak up so we can
> arrange an alternate (please don't hesitate to do so, even if you are
> the only one).
>
Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
That works for me.
On Jun 5, 2006, at 12:38 PM, Simon Nash wrote:
> Friday is OK for me, but I'd prefer not to go too late in this
> time zone. Can we do this from 8.00 to 10.00 am PDT?
>
> Simon
>
> Jeremy Boynes wrote:
>
>> Kenneth Tam wrote:
>>> I am very interested in this, but the short notice also concerns me.
>>> Can we push this out to at least the end of the week (say
>>> Friday?) or
>>> sometime next week so that more people on the list get a chance to
>>> find out about it and fit it into their schedules?
>>>
>> Friday would work for me too.
>>> Also, Jim & Jeremy -- if you guys have anything in the way of
>>> explanatory material that you could circulate on the list/wiki
>>> before
>>> the presentation, I think that would be very useful.. certainly I
>>> could use a little more context to help with my own browsing.
>>>
>> I think the key area from a conceptal side would be the SPI
>> module. In
>> M1, the interfaces and implementation were mixed together in the core
>> module and we refactored this to move all the interfaces and base
>> classes into spi with just the implementation in core. A typical
>> container or binding extension should be able to depend just on
>> SPI and
>> not need the core (unless it decides to).
>> The intention is that all the SPI classes should have JavaDoc that
>> clearly explains what they are for - we may not be there yet, but
>> that's
>> the goal. Any questions on them would be good so that it can be
>> fed back
>> into code.
>> --
>> Jeremy
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Simon Nash <na...@hursley.ibm.com>.
Friday is OK for me, but I'd prefer not to go too late in this
time zone. Can we do this from 8.00 to 10.00 am PDT?
Simon
Jeremy Boynes wrote:
> Kenneth Tam wrote:
>
>>I am very interested in this, but the short notice also concerns me.
>>Can we push this out to at least the end of the week (say Friday?) or
>>sometime next week so that more people on the list get a chance to
>>find out about it and fit it into their schedules?
>>
>
>
> Friday would work for me too.
>
>
>>Also, Jim & Jeremy -- if you guys have anything in the way of
>>explanatory material that you could circulate on the list/wiki before
>>the presentation, I think that would be very useful.. certainly I
>>could use a little more context to help with my own browsing.
>>
>
>
> I think the key area from a conceptal side would be the SPI module. In
> M1, the interfaces and implementation were mixed together in the core
> module and we refactored this to move all the interfaces and base
> classes into spi with just the implementation in core. A typical
> container or binding extension should be able to depend just on SPI and
> not need the core (unless it decides to).
>
> The intention is that all the SPI classes should have JavaDoc that
> clearly explains what they are for - we may not be there yet, but that's
> the goal. Any questions on them would be good so that it can be fed back
> into code.
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jeremy Boynes <jb...@apache.org>.
Kenneth Tam wrote:
> I am very interested in this, but the short notice also concerns me.
> Can we push this out to at least the end of the week (say Friday?) or
> sometime next week so that more people on the list get a chance to
> find out about it and fit it into their schedules?
>
Friday would work for me too.
> Also, Jim & Jeremy -- if you guys have anything in the way of
> explanatory material that you could circulate on the list/wiki before
> the presentation, I think that would be very useful.. certainly I
> could use a little more context to help with my own browsing.
>
I think the key area from a conceptal side would be the SPI module. In
M1, the interfaces and implementation were mixed together in the core
module and we refactored this to move all the interfaces and base
classes into spi with just the implementation in core. A typical
container or binding extension should be able to depend just on SPI and
not need the core (unless it decides to).
The intention is that all the SPI classes should have JavaDoc that
clearly explains what they are for - we may not be there yet, but that's
the goal. Any questions on them would be good so that it can be fed back
into code.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Project IP, was: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
Thanks Jeremy
I fully understand the ICLA and CCLA process. After all as an Apache
Committer I've signed one and I also was involved in pushing Steve
Gerdt at IBM to develop a corporate policy for CLAs when I was at IBM.
As regards the feedback license, I wasn't questioning the ability for
Apache IP to move to the spec group, though that may be an issue its
not one that I'm concerned with.
Let me be 100% clear. I am concerned about the committal of IP *into*
Apache from the Spec Group when the spec group has not officially
released this IP. I think the documents from Mike will help clarify
this, so I'll wait and see what Mike sends through.
Thanks again
Paul
On 6/8/06, Jeremy Boynes <jb...@apache.org> wrote:
> Paul Fremantle wrote:
> >
> >> and track the specs
> >
> >
> > That is the concern, if we are tracking unpublished specs. If you are
> > under an NDA with the spec group, then you may not have had the right
> > to contribute the code that you contributed to the sandbox. As no-one
> > has yet answered my questions about the the IP arrangements of the
> > spec group this is pure supposition. Maybe someone will get round to
> > answering those questions. Or maybe the NDA is under NDA and no-one is
> > allowed to post that information here :-)
> >
>
> The key thing here is that all contributors have signed a CLA that says
> that they do have the right to contribute the IP. In these times most
> software developers need to deal with Confidential material in some form
> whether it is part of their employment, a contract they are involved in,
> or other discussions. As it can't track all these arrangements, the ASF
> relies on its contributors to honour the contract that they signed.
>
> The feedback agreement is linked off the spec homepages but here's a
> direct link:
> http://www.alphaworks.ibm.com/wsspec/agreement/sca
>
> As an indicator of how the process works you can see that the only
> information that is Confidential is that which is explicitly marked as
> "confidential" - which isn't much and certainly isn't stuff that we
> discuss in the project.
>
> As Jim said, you can also get the full participant agreement from Mike.
> I've pinged him as well and asked him to respond.
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Project IP, was: Recursive core architectural overview
Posted by Jeremy Boynes <jb...@apache.org>.
Paul Fremantle wrote:
>
>> and track the specs
>
>
> That is the concern, if we are tracking unpublished specs. If you are
> under an NDA with the spec group, then you may not have had the right
> to contribute the code that you contributed to the sandbox. As no-one
> has yet answered my questions about the the IP arrangements of the
> spec group this is pure supposition. Maybe someone will get round to
> answering those questions. Or maybe the NDA is under NDA and no-one is
> allowed to post that information here :-)
>
The key thing here is that all contributors have signed a CLA that says
that they do have the right to contribute the IP. In these times most
software developers need to deal with Confidential material in some form
whether it is part of their employment, a contract they are involved in,
or other discussions. As it can't track all these arrangements, the ASF
relies on its contributors to honour the contract that they signed.
The feedback agreement is linked off the spec homepages but here's a
direct link:
http://www.alphaworks.ibm.com/wsspec/agreement/sca
As an indicator of how the process works you can see that the only
information that is Confidential is that which is explicitly marked as
"confidential" - which isn't much and certainly isn't stuff that we
discuss in the project.
As Jim said, you can also get the full participant agreement from Mike.
I've pinged him as well and asked him to respond.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
Jeremy
Thanks for the detailed reply.
> Geronimo has private lists for stuff under NDA and has had various
> people on different expert groups (e.g. a couple of us were on JSR-220).
> In general, there are a lot of Apache projects that work with the JCP
> and deal with the closed nature of JSRs - Tomcat, Portal, Axis come to mind.
1) Apache is a member of the JCP. Apache is not a member of the SCA
spec group. (Whose name I don't even know.)
2) I believe that the only geronimo private list is for the TCK, and
only used for TCK compliance tests and results. I'm not sure that
there is a good analogy as there is no Spec based IP being donated to
that list. Furthermore it took a long time to clear up the IP issues
between the JCP and Apache. I have no faith that that model is
transferrable without legal review.
> Apache projects also provide functions over and above published
> specifications, features that are relevant to the users and developers
> of the project. Sometimes those innovations get picked up and included
> by specification bodies - open source shaping the future.
That is great. The code we write in Apache is completely open and
guaranteed by the ICLAs that users commit code under, and by the
Apache License.
> We just had an
> example of this with Tuscany where thoughts on a recursive structure
> (which have been in mind since before we came to Apache) contributed to
> a significant change in the specification.
Cool. Glad to hear it. I am very pleased by this because I hoped that
Tuscany would feel free to innovate beyond the published SCA spec.
> As a project, we can continue to implement a now-obsolete draft from
> last year, or we can innovate, influence
Yes we can innovate and influence. That goes from Apache -> Spec
Group, which is fine.
> and track the specs
That is the concern, if we are tracking unpublished specs. If you are
under an NDA with the spec group, then you may not have had the right
to contribute the code that you contributed to the sandbox. As no-one
has yet answered my questions about the the IP arrangements of the
spec group this is pure supposition. Maybe someone will get round to
answering those questions. Or maybe the NDA is under NDA and no-one is
allowed to post that information here :-)
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
On Jun 7, 2006, at 2:43 PM, Jeremy Boynes wrote:
> Paul Fremantle wrote:
>> Jim
>>
>> Its a great question. I think the answer is that they stick to
>> published specs, which is what I was expecting Tuscany to do given
>> the
>> closed nature of the spec group. I'll ask around to find out.
>>
>
> Geronimo has private lists for stuff under NDA and has had various
> people on different expert groups (e.g. a couple of us were on
> JSR-220).
> In general, there are a lot of Apache projects that work with the JCP
> and deal with the closed nature of JSRs - Tomcat, Portal, Axis come
> to mind.
>
> Apache projects also provide functions over and above published
> specifications, features that are relevant to the users and developers
> of the project. Sometimes those innovations get picked up and included
> by specification bodies - open source shaping the future. We just
> had an
> example of this with Tuscany where thoughts on a recursive structure
> (which have been in mind since before we came to Apache)
> contributed to
> a significant change in the specification.
>
> Remember too that the SCA specifications are still preliminary - they
> could be compared to Community or Early Draft review stages in the
> JCP.
> The expectation should be that they will change - I actually expected
> changes would be happening faster than they are.
>
> As a project, we can continue to implement a now-obsolete draft from
> last year, or we can innovate, influence and track the specs to the
> greatest extent that we can.
>
As additional background, there will be another spec "refresh" with
the recursive model in a matter of weeks. I'd like to see us have
support for that as soon as possible, particularly since many of the
ideas were worked on here as far back as December.
> I'm participating here because I want to build some software that
> makes
> it easier to build and run applications in the new, complex,
> service-enabled world; I think the rest of the community has similar
> motives. The SCA spec contains a good codification of some of the
> challenges in this space and proposes solutions for them through its
> programming and assembly models. In the end though it's code that
> talks
> and whether we are successful will depend on what we as a community
> build rather than what the spec says.
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jeremy Boynes <jb...@apache.org>.
Paul Fremantle wrote:
> Jim
>
> Its a great question. I think the answer is that they stick to
> published specs, which is what I was expecting Tuscany to do given the
> closed nature of the spec group. I'll ask around to find out.
>
Geronimo has private lists for stuff under NDA and has had various
people on different expert groups (e.g. a couple of us were on JSR-220).
In general, there are a lot of Apache projects that work with the JCP
and deal with the closed nature of JSRs - Tomcat, Portal, Axis come to mind.
Apache projects also provide functions over and above published
specifications, features that are relevant to the users and developers
of the project. Sometimes those innovations get picked up and included
by specification bodies - open source shaping the future. We just had an
example of this with Tuscany where thoughts on a recursive structure
(which have been in mind since before we came to Apache) contributed to
a significant change in the specification.
Remember too that the SCA specifications are still preliminary - they
could be compared to Community or Early Draft review stages in the JCP.
The expectation should be that they will change - I actually expected
changes would be happening faster than they are.
As a project, we can continue to implement a now-obsolete draft from
last year, or we can innovate, influence and track the specs to the
greatest extent that we can.
I'm participating here because I want to build some software that makes
it easier to build and run applications in the new, complex,
service-enabled world; I think the rest of the community has similar
motives. The SCA spec contains a good codification of some of the
challenges in this space and proposes solutions for them through its
programming and assembly models. In the end though it's code that talks
and whether we are successful will depend on what we as a community
build rather than what the spec says.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
Jim
Its a great question. I think the answer is that they stick to
published specs, which is what I was expecting Tuscany to do given the
closed nature of the spec group. I'll ask around to find out.
Paul
On 6/7/06, Jim Marino <jm...@myromatours.com> wrote:
> Paul,
>
> I'm going to ask others more versed in legalities to jump in
> regarding your questions...I do have a quick question though: how
> does Geronimo handle this as I believe the JCP IP rules are far more
> restrictive than those associated with the specs?
>
> Thanks,
> Jim
>
>
> On Jun 7, 2006, at 11:41 AM, Paul Fremantle wrote:
>
> > Simon
> >
> > I'm have concerns about both these approaches.
> >
> > Regarding the first proposal, there might be IP or other requirements
> > that joining the spec collaboration involves that might not be
> > suitable for some Tuscany committers. I'm not clear what is involved
> > in joining the spec group but I'm guessing based on your note that
> > there are possibly non-disclosure agreements and IP agreements. I'm
> > concerned that there might end up two classes of committers - those
> > with access to the spec group and those without.
> >
> > Regarding the second proposal, this seems a little anti-thetical to
> > the Apache approach... where generally everything is done in the open.
> > I'm also concerned about the implications of committing code to
> > Tuscany based on a private mailing list. The ICLA states:
> > "You represent that you are legally entitled to grant the above
> > license." There are also other related clauses. What I'm concerned is
> > that committers might be committing code that is based on things they
> > learnt under a non-disclosure agreement.
> >
> > I'm sure none of these issues is insurmountable, but I think we need
> > to have a clear approach before we try and exit incubation. It might
> > also be worth consulting the legal team at Apache once we have a
> > clearer idea of what the issues are.
> >
> > Paul
> >
> > On 6/7/06, Simon Nash <na...@hursley.ibm.com> wrote:
> >> I can think of a couple of options that might work.
> >>
> >> 1. All Tuscany participants could join the spec collaboration and
> >> get first-hand information on issues and agreed changes.
> >> 2. Set up a private Apache mailing list on which non-public spec
> >> information could be distributed and discussions could take
> >> place.
> >>
> >> I think the second option is better, since it's probably easier for
> >> people not working for members of the collaboration to get on a
> >> private Apache list than to sign up as collaboration members.
> >> This will require agreement from the collaboration team, since it
> >> would open up access to this information to people who have not
> >> signed the formal collaboration agreement. Maybe there could be a
> >> lighter-weight "open source" version of the collaboration agreement
> >> designed for this purpose.
> >>
> >> Simon
> >>
> >> Jim Marino wrote:
> >>
> >> > Good question...
> >> >
> >> > In the spec group, one of the major changes we are currently
> >> > undertaking is a move to a recursive model where components can
> >> either
> >> > be leaf-types ("atomic") or composite, in which case they may
> >> contain
> >> > children. In previous versions of the spec we had a two-level
> >> model
> >> > (module components and components which were leaf-types). The
> >> recursive
> >> > model simplifies a great deal since it eliminates a number of
> >> > unnecessary concepts. For example, components used to offer
> >> services
> >> > and have references while module components offered entry
> >> points and
> >> > had external services. Since there is a common type, component,
> >> we can
> >> > dispense with the separate concepts of entry point and external
> >> service
> >> > and just call them "service" (~entry point) and
> >> "reference" (~external
> >> > service). I think this makes sense from a conceptual standpoint
> >> since a
> >> > composite component may have a service bound to some protocol/
> >> transport
> >> > combination such as SOAP/HTTP while a service on a POJO may be
> >> thought
> >> > of as having a "shared memory"/by- reference binding. Besides
> >> making the
> >> > implementation more concise, It also makes slideware easier
> >> since we
> >> > have the same picture at different levels :-)
> >> >
> >> > In any event, this was one of the topics we were intending to
> >> cover on
> >> > the call.
> >> >
> >> > I think this is a good question specifically because I believe the
> >> > coordination between the spec collaboration and the Tuscany
> >> community
> >> > could be a lot better. This partly arises from the fact that
> >> the people
> >> > such as myself and Jeremy who wear both hats are swamped with
> >> work and
> >> > things sometimes get delayed. Another reason for the less- than-
> >> ideal
> >> > situation is that a collaboration model between the spec group and
> >> > Tuscany has not been put in place. Regarding the latter, I believe
> >> > there are some systemic improvements we can make such as not
> >> having to
> >> > channel issues through Jeremy or myself as well as having more
> >> defined
> >> > input mechanisms between the two groups. The spec group is
> >> aware of the
> >> > issue as well so I think it would be fruitful for us to come up
> >> with
> >> > some concrete proposals we could discuss with them.
> >> >
> >> > Ideas?
> >> >
> >> > Jim
> >> >
> >> >
> >> > On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
> >> >
> >> >> By the way can someone explain what the term "Recursive Core
> >> >> Architecture" means?
> >> >>
> >> >> Paul
> >> >>
> >> >> On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >>
> >> >>> It looks as if we have the choice of Thursday or Friday this
> >> week, or
> >> >>> rescheduling for two weeks. I'd prefer we do it this week.
> >> >>>
> >> >>> Jim
> >> >>>
> >> >>> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
> >> >>>
> >> >>> > Next week would be better for me. I'm landing home from the
> >> US on
> >> >>> > Friday and 8-10PST is 4-6pm on Friday evening which aint
> >> popular in
> >> >>> > blighty :-)
> >> >>> >
> >> >>> > Paul
> >> >>> >
> >> >>> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >>> >> I'm out all next week so it sounds as if Friday is the
> >> best time for
> >> >>> >> most people.
> >> >>> >>
> >> >>> >> Jim
> >> >>> >>
> >> >>> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
> >> >>> >>
> >> >>> >> > I like to second all of what Ant wrote and also Ken Tam
> >> asked
> >> >>> if it
> >> >>> >> > could not be delayed till next week. I'd like to be up
> >> to speed
> >> >>> and
> >> >>> >> > just a few days more would help to digest it all to be more
> >> >>> >> > informed, but I'll go with Friday if that's what it is.
> >> >>> >> > ant elder wrote:
> >> >>> >> >> I agree 100% with Ken, could you give just a little more
> >> >>> >> >> information about
> >> >>> >> >> whats going on here? That email just gives hints -
> >> there's been
> >> >>> >> >> some SCA
> >> >>> >> >> spec changes, there's some code in the the sandbox for
> >> "recursive
> >> >>> >> >> core
> >> >>> >> >> architecture work" and "to clearly demarcate the runtime
> >> >>> extension
> >> >>> >> >> mechanism."
> >> >>> >> >>
> >> >>> >> >> What are the spec changes, are there any new spec documents
> >> >>> people
> >> >>> >> >> can
> >> >>> >> >> review?
> >> >>> >> >>
> >> >>> >> >> Is there anything else that has changed from the M1
> >> release code
> >> >>> >> >> to whats in
> >> >>> >> >> the sandbox?
> >> >>> >> >>
> >> >>> >> >> Whats the state of the sandbox code, does it work, are
> >> there any
> >> >>> >> >> samples,
> >> >>> >> >> does bigbank run?
> >> >>> >> >>
> >> >>> >> >> What is the intention for the future of the sandbox code?
> >> >>> >> >>
> >> >>> >> >> It sounds like we're being asked to just go look at
> >> some code in
> >> >>> >> >> the sandbox
> >> >>> >> >> and work all this out for ourselves. There's a lot of
> >> people
> >> >>> >> >> listening who
> >> >>> >> >> have no idea whats going on, so some more detailed
> >> background
> >> >>> >> >> information
> >> >>> >> >> would really help.
> >> >>> >> >>
> >> >>> >> >> Friday is bad for me I can't make anything much after
> >> 9am PDT,
> >> >>> >> >> same for
> >> >>> >> >> Mondays after 5:30BST, but i'll fit in with most times any
> >> >>> >> other day.
> >> >>> >> >>
> >> >>> >> >> ...ant
> >> >>> >> >>
> >> >>> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
> >> >>> >> >>>
> >> >>> >> >>> I am very interested in this, but the short notice also
> >> >>> >> concerns me.
> >> >>> >> >>> Can we push this out to at least the end of the week (say
> >> >>> >> >>> Friday?) or
> >> >>> >> >>> sometime next week so that more people on the list get a
> >> >>> >> chance to
> >> >>> >> >>> find out about it and fit it into their schedules?
> >> >>> >> >>>
> >> >>> >> >>> Also, Jim & Jeremy -- if you guys have anything in the
> >> way of
> >> >>> >> >>> explanatory material that you could circulate on the
> >> list/wiki
> >> >>> >> >>> before
> >> >>> >> >>> the presentation, I think that would be very useful..
> >> >>> certainly I
> >> >>> >> >>> could use a little more context to help with my own
> >> browsing.
> >> >>> >> >>>
> >> >>> >> >>> thanks,
> >> >>> >> >>> k
> >> >>> >> >>>
> >> >>> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> >>> >> >>> > Jim Marino wrote:
> >> >>> >> >>> > > Hi,
> >> >>> >> >>> > >
> >> >>> >> >>> > > There has been some mention offline of Jeremy and I
> >> >>> >> providing an
> >> >>> >> >>> > > overview of changes to the SCA specifications and
> >> related
> >> >>> >> >>> recursive
> >> >>> >> >>> > > core architecture work going on in the sandbox,
> >> perhaps
> >> >>> >> >>> Wednesday. I'm
> >> >>> >> >>> > > happy to do this, however, I'm a bit concerned that
> >> since
> >> >>> >> >>> this has
> >> >>> >> >>> not
> >> >>> >> >>> > > been brought up on the list interested people may
> >> not be
> >> >>> >> >>> able to
> >> >>> >> >>> attend
> >> >>> >> >>> > > on short notice. Also, a time has not been
> >> mentioned. I
> >> >>> >> propose
> >> >>> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-
> >> free
> >> >>> dial-
> >> >>> >> >>> in,
> >> >>> >> >>> which
> >> >>> >> >>> > > will be provided later.
> >> >>> >> >>> > >
> >> >>> >> >>> > > If interested people cannot make that time, please
> >> speak up
> >> >>> >> >>> so we can
> >> >>> >> >>> > > arrange an alternate (please don't hesitate to do so,
> >> >>> even if
> >> >>> >> >>> you are
> >> >>> >> >>> > > the only one).
> >> >>> >> >>> > >
> >> >>> >> >>> >
> >> >>> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do
> >> before or
> >> >>> >> >>> after.
> >> >>> >> >>> > --
> >> >>> >> >>> > Jeremy
> >> >>> >> >>> >
> >> >>> >> >>> >
> >> >>> >> >>>
> >> >>> >>
> >> --------------------------------------------------------------------
> >> >>> >> >>> -
> >> >>> >> >>> > To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >>> >> >>> > For additional commands, e-mail: tuscany-dev-
> >> >>> help@ws.apache.org
> >> >>> >> >>> >
> >> >>> >> >>> >
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >>
> >> --------------------------------------------------------------------
> >> >>> >> >>> -
> >> >>> >> >>> To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >>> >> >>> For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >> >>
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> >> > To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >>> >> > For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >>> >> >
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >>> >> For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >>> >>
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Paul Fremantle
> >> >>> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >> >>> >
> >> >>> > http://bloglines.com/blog/paulfremantle
> >> >>> > paul@wso2.com
> >> >>> >
> >> >>> > "Oxygenating the Web Service Platform", www.wso2.com
> >> >>> >
> >> >>> >
> >> ---------------------------------------------------------------------
> >> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Paul Fremantle
> >> >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >> >>
> >> >> http://bloglines.com/blog/paulfremantle
> >> >> paul@wso2.com
> >> >>
> >> >> "Oxygenating the Web Service Platform", www.wso2.com
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> Simon C Nash IBM Distinguished Engineer
> >> Hursley Park, Winchester, UK nash@hursley.ibm.com
> >> Tel. +44-1962-815156 Fax +44-1962-818999
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
Paul,
I'm going to ask others more versed in legalities to jump in
regarding your questions...I do have a quick question though: how
does Geronimo handle this as I believe the JCP IP rules are far more
restrictive than those associated with the specs?
Thanks,
Jim
On Jun 7, 2006, at 11:41 AM, Paul Fremantle wrote:
> Simon
>
> I'm have concerns about both these approaches.
>
> Regarding the first proposal, there might be IP or other requirements
> that joining the spec collaboration involves that might not be
> suitable for some Tuscany committers. I'm not clear what is involved
> in joining the spec group but I'm guessing based on your note that
> there are possibly non-disclosure agreements and IP agreements. I'm
> concerned that there might end up two classes of committers - those
> with access to the spec group and those without.
>
> Regarding the second proposal, this seems a little anti-thetical to
> the Apache approach... where generally everything is done in the open.
> I'm also concerned about the implications of committing code to
> Tuscany based on a private mailing list. The ICLA states:
> "You represent that you are legally entitled to grant the above
> license." There are also other related clauses. What I'm concerned is
> that committers might be committing code that is based on things they
> learnt under a non-disclosure agreement.
>
> I'm sure none of these issues is insurmountable, but I think we need
> to have a clear approach before we try and exit incubation. It might
> also be worth consulting the legal team at Apache once we have a
> clearer idea of what the issues are.
>
> Paul
>
> On 6/7/06, Simon Nash <na...@hursley.ibm.com> wrote:
>> I can think of a couple of options that might work.
>>
>> 1. All Tuscany participants could join the spec collaboration and
>> get first-hand information on issues and agreed changes.
>> 2. Set up a private Apache mailing list on which non-public spec
>> information could be distributed and discussions could take
>> place.
>>
>> I think the second option is better, since it's probably easier for
>> people not working for members of the collaboration to get on a
>> private Apache list than to sign up as collaboration members.
>> This will require agreement from the collaboration team, since it
>> would open up access to this information to people who have not
>> signed the formal collaboration agreement. Maybe there could be a
>> lighter-weight "open source" version of the collaboration agreement
>> designed for this purpose.
>>
>> Simon
>>
>> Jim Marino wrote:
>>
>> > Good question...
>> >
>> > In the spec group, one of the major changes we are currently
>> > undertaking is a move to a recursive model where components can
>> either
>> > be leaf-types ("atomic") or composite, in which case they may
>> contain
>> > children. In previous versions of the spec we had a two-level
>> model
>> > (module components and components which were leaf-types). The
>> recursive
>> > model simplifies a great deal since it eliminates a number of
>> > unnecessary concepts. For example, components used to offer
>> services
>> > and have references while module components offered entry
>> points and
>> > had external services. Since there is a common type, component,
>> we can
>> > dispense with the separate concepts of entry point and external
>> service
>> > and just call them "service" (~entry point) and
>> "reference" (~external
>> > service). I think this makes sense from a conceptual standpoint
>> since a
>> > composite component may have a service bound to some protocol/
>> transport
>> > combination such as SOAP/HTTP while a service on a POJO may be
>> thought
>> > of as having a "shared memory"/by- reference binding. Besides
>> making the
>> > implementation more concise, It also makes slideware easier
>> since we
>> > have the same picture at different levels :-)
>> >
>> > In any event, this was one of the topics we were intending to
>> cover on
>> > the call.
>> >
>> > I think this is a good question specifically because I believe the
>> > coordination between the spec collaboration and the Tuscany
>> community
>> > could be a lot better. This partly arises from the fact that
>> the people
>> > such as myself and Jeremy who wear both hats are swamped with
>> work and
>> > things sometimes get delayed. Another reason for the less- than-
>> ideal
>> > situation is that a collaboration model between the spec group and
>> > Tuscany has not been put in place. Regarding the latter, I believe
>> > there are some systemic improvements we can make such as not
>> having to
>> > channel issues through Jeremy or myself as well as having more
>> defined
>> > input mechanisms between the two groups. The spec group is
>> aware of the
>> > issue as well so I think it would be fruitful for us to come up
>> with
>> > some concrete proposals we could discuss with them.
>> >
>> > Ideas?
>> >
>> > Jim
>> >
>> >
>> > On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
>> >
>> >> By the way can someone explain what the term "Recursive Core
>> >> Architecture" means?
>> >>
>> >> Paul
>> >>
>> >> On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >>
>> >>> It looks as if we have the choice of Thursday or Friday this
>> week, or
>> >>> rescheduling for two weeks. I'd prefer we do it this week.
>> >>>
>> >>> Jim
>> >>>
>> >>> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
>> >>>
>> >>> > Next week would be better for me. I'm landing home from the
>> US on
>> >>> > Friday and 8-10PST is 4-6pm on Friday evening which aint
>> popular in
>> >>> > blighty :-)
>> >>> >
>> >>> > Paul
>> >>> >
>> >>> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >>> >> I'm out all next week so it sounds as if Friday is the
>> best time for
>> >>> >> most people.
>> >>> >>
>> >>> >> Jim
>> >>> >>
>> >>> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
>> >>> >>
>> >>> >> > I like to second all of what Ant wrote and also Ken Tam
>> asked
>> >>> if it
>> >>> >> > could not be delayed till next week. I'd like to be up
>> to speed
>> >>> and
>> >>> >> > just a few days more would help to digest it all to be more
>> >>> >> > informed, but I'll go with Friday if that's what it is.
>> >>> >> > ant elder wrote:
>> >>> >> >> I agree 100% with Ken, could you give just a little more
>> >>> >> >> information about
>> >>> >> >> whats going on here? That email just gives hints -
>> there's been
>> >>> >> >> some SCA
>> >>> >> >> spec changes, there's some code in the the sandbox for
>> "recursive
>> >>> >> >> core
>> >>> >> >> architecture work" and "to clearly demarcate the runtime
>> >>> extension
>> >>> >> >> mechanism."
>> >>> >> >>
>> >>> >> >> What are the spec changes, are there any new spec documents
>> >>> people
>> >>> >> >> can
>> >>> >> >> review?
>> >>> >> >>
>> >>> >> >> Is there anything else that has changed from the M1
>> release code
>> >>> >> >> to whats in
>> >>> >> >> the sandbox?
>> >>> >> >>
>> >>> >> >> Whats the state of the sandbox code, does it work, are
>> there any
>> >>> >> >> samples,
>> >>> >> >> does bigbank run?
>> >>> >> >>
>> >>> >> >> What is the intention for the future of the sandbox code?
>> >>> >> >>
>> >>> >> >> It sounds like we're being asked to just go look at
>> some code in
>> >>> >> >> the sandbox
>> >>> >> >> and work all this out for ourselves. There's a lot of
>> people
>> >>> >> >> listening who
>> >>> >> >> have no idea whats going on, so some more detailed
>> background
>> >>> >> >> information
>> >>> >> >> would really help.
>> >>> >> >>
>> >>> >> >> Friday is bad for me I can't make anything much after
>> 9am PDT,
>> >>> >> >> same for
>> >>> >> >> Mondays after 5:30BST, but i'll fit in with most times any
>> >>> >> other day.
>> >>> >> >>
>> >>> >> >> ...ant
>> >>> >> >>
>> >>> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>> >>> >> >>>
>> >>> >> >>> I am very interested in this, but the short notice also
>> >>> >> concerns me.
>> >>> >> >>> Can we push this out to at least the end of the week (say
>> >>> >> >>> Friday?) or
>> >>> >> >>> sometime next week so that more people on the list get a
>> >>> >> chance to
>> >>> >> >>> find out about it and fit it into their schedules?
>> >>> >> >>>
>> >>> >> >>> Also, Jim & Jeremy -- if you guys have anything in the
>> way of
>> >>> >> >>> explanatory material that you could circulate on the
>> list/wiki
>> >>> >> >>> before
>> >>> >> >>> the presentation, I think that would be very useful..
>> >>> certainly I
>> >>> >> >>> could use a little more context to help with my own
>> browsing.
>> >>> >> >>>
>> >>> >> >>> thanks,
>> >>> >> >>> k
>> >>> >> >>>
>> >>> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> >>> >> >>> > Jim Marino wrote:
>> >>> >> >>> > > Hi,
>> >>> >> >>> > >
>> >>> >> >>> > > There has been some mention offline of Jeremy and I
>> >>> >> providing an
>> >>> >> >>> > > overview of changes to the SCA specifications and
>> related
>> >>> >> >>> recursive
>> >>> >> >>> > > core architecture work going on in the sandbox,
>> perhaps
>> >>> >> >>> Wednesday. I'm
>> >>> >> >>> > > happy to do this, however, I'm a bit concerned that
>> since
>> >>> >> >>> this has
>> >>> >> >>> not
>> >>> >> >>> > > been brought up on the list interested people may
>> not be
>> >>> >> >>> able to
>> >>> >> >>> attend
>> >>> >> >>> > > on short notice. Also, a time has not been
>> mentioned. I
>> >>> >> propose
>> >>> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-
>> free
>> >>> dial-
>> >>> >> >>> in,
>> >>> >> >>> which
>> >>> >> >>> > > will be provided later.
>> >>> >> >>> > >
>> >>> >> >>> > > If interested people cannot make that time, please
>> speak up
>> >>> >> >>> so we can
>> >>> >> >>> > > arrange an alternate (please don't hesitate to do so,
>> >>> even if
>> >>> >> >>> you are
>> >>> >> >>> > > the only one).
>> >>> >> >>> > >
>> >>> >> >>> >
>> >>> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do
>> before or
>> >>> >> >>> after.
>> >>> >> >>> > --
>> >>> >> >>> > Jeremy
>> >>> >> >>> >
>> >>> >> >>> >
>> >>> >> >>>
>> >>> >>
>> --------------------------------------------------------------------
>> >>> >> >>> -
>> >>> >> >>> > To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >>> >> >>> > For additional commands, e-mail: tuscany-dev-
>> >>> help@ws.apache.org
>> >>> >> >>> >
>> >>> >> >>> >
>> >>> >> >>>
>> >>> >> >>>
>> >>> >>
>> --------------------------------------------------------------------
>> >>> >> >>> -
>> >>> >> >>> To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >>> >> >>> For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >>> >> >>>
>> >>> >> >>>
>> >>> >> >>
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>>
>> ---------------------------------------------------------------------
>> >>> >> > To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >>> >> > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >>
>> >>>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> >> For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Paul Fremantle
>> >>> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>> >>> >
>> >>> > http://bloglines.com/blog/paulfremantle
>> >>> > paul@wso2.com
>> >>> >
>> >>> > "Oxygenating the Web Service Platform", www.wso2.com
>> >>> >
>> >>> >
>> ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>> >
>> >>>
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Paul Fremantle
>> >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>> >>
>> >> http://bloglines.com/blog/paulfremantle
>> >> paul@wso2.com
>> >>
>> >> "Oxygenating the Web Service Platform", www.wso2.com
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>> >
>>
>> --
>> Simon C Nash IBM Distinguished Engineer
>> Hursley Park, Winchester, UK nash@hursley.ibm.com
>> Tel. +44-1962-815156 Fax +44-1962-818999
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
Simon
I'm have concerns about both these approaches.
Regarding the first proposal, there might be IP or other requirements
that joining the spec collaboration involves that might not be
suitable for some Tuscany committers. I'm not clear what is involved
in joining the spec group but I'm guessing based on your note that
there are possibly non-disclosure agreements and IP agreements. I'm
concerned that there might end up two classes of committers - those
with access to the spec group and those without.
Regarding the second proposal, this seems a little anti-thetical to
the Apache approach... where generally everything is done in the open.
I'm also concerned about the implications of committing code to
Tuscany based on a private mailing list. The ICLA states:
"You represent that you are legally entitled to grant the above
license." There are also other related clauses. What I'm concerned is
that committers might be committing code that is based on things they
learnt under a non-disclosure agreement.
I'm sure none of these issues is insurmountable, but I think we need
to have a clear approach before we try and exit incubation. It might
also be worth consulting the legal team at Apache once we have a
clearer idea of what the issues are.
Paul
On 6/7/06, Simon Nash <na...@hursley.ibm.com> wrote:
> I can think of a couple of options that might work.
>
> 1. All Tuscany participants could join the spec collaboration and
> get first-hand information on issues and agreed changes.
> 2. Set up a private Apache mailing list on which non-public spec
> information could be distributed and discussions could take place.
>
> I think the second option is better, since it's probably easier for
> people not working for members of the collaboration to get on a
> private Apache list than to sign up as collaboration members.
> This will require agreement from the collaboration team, since it
> would open up access to this information to people who have not
> signed the formal collaboration agreement. Maybe there could be a
> lighter-weight "open source" version of the collaboration agreement
> designed for this purpose.
>
> Simon
>
> Jim Marino wrote:
>
> > Good question...
> >
> > In the spec group, one of the major changes we are currently
> > undertaking is a move to a recursive model where components can either
> > be leaf-types ("atomic") or composite, in which case they may contain
> > children. In previous versions of the spec we had a two-level model
> > (module components and components which were leaf-types). The recursive
> > model simplifies a great deal since it eliminates a number of
> > unnecessary concepts. For example, components used to offer services
> > and have references while module components offered entry points and
> > had external services. Since there is a common type, component, we can
> > dispense with the separate concepts of entry point and external service
> > and just call them "service" (~entry point) and "reference" (~external
> > service). I think this makes sense from a conceptual standpoint since a
> > composite component may have a service bound to some protocol/transport
> > combination such as SOAP/HTTP while a service on a POJO may be thought
> > of as having a "shared memory"/by- reference binding. Besides making the
> > implementation more concise, It also makes slideware easier since we
> > have the same picture at different levels :-)
> >
> > In any event, this was one of the topics we were intending to cover on
> > the call.
> >
> > I think this is a good question specifically because I believe the
> > coordination between the spec collaboration and the Tuscany community
> > could be a lot better. This partly arises from the fact that the people
> > such as myself and Jeremy who wear both hats are swamped with work and
> > things sometimes get delayed. Another reason for the less- than-ideal
> > situation is that a collaboration model between the spec group and
> > Tuscany has not been put in place. Regarding the latter, I believe
> > there are some systemic improvements we can make such as not having to
> > channel issues through Jeremy or myself as well as having more defined
> > input mechanisms between the two groups. The spec group is aware of the
> > issue as well so I think it would be fruitful for us to come up with
> > some concrete proposals we could discuss with them.
> >
> > Ideas?
> >
> > Jim
> >
> >
> > On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
> >
> >> By the way can someone explain what the term "Recursive Core
> >> Architecture" means?
> >>
> >> Paul
> >>
> >> On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >>> It looks as if we have the choice of Thursday or Friday this week, or
> >>> rescheduling for two weeks. I'd prefer we do it this week.
> >>>
> >>> Jim
> >>>
> >>> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
> >>>
> >>> > Next week would be better for me. I'm landing home from the US on
> >>> > Friday and 8-10PST is 4-6pm on Friday evening which aint popular in
> >>> > blighty :-)
> >>> >
> >>> > Paul
> >>> >
> >>> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >>> >> I'm out all next week so it sounds as if Friday is the best time for
> >>> >> most people.
> >>> >>
> >>> >> Jim
> >>> >>
> >>> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
> >>> >>
> >>> >> > I like to second all of what Ant wrote and also Ken Tam asked
> >>> if it
> >>> >> > could not be delayed till next week. I'd like to be up to speed
> >>> and
> >>> >> > just a few days more would help to digest it all to be more
> >>> >> > informed, but I'll go with Friday if that's what it is.
> >>> >> > ant elder wrote:
> >>> >> >> I agree 100% with Ken, could you give just a little more
> >>> >> >> information about
> >>> >> >> whats going on here? That email just gives hints - there's been
> >>> >> >> some SCA
> >>> >> >> spec changes, there's some code in the the sandbox for "recursive
> >>> >> >> core
> >>> >> >> architecture work" and "to clearly demarcate the runtime
> >>> extension
> >>> >> >> mechanism."
> >>> >> >>
> >>> >> >> What are the spec changes, are there any new spec documents
> >>> people
> >>> >> >> can
> >>> >> >> review?
> >>> >> >>
> >>> >> >> Is there anything else that has changed from the M1 release code
> >>> >> >> to whats in
> >>> >> >> the sandbox?
> >>> >> >>
> >>> >> >> Whats the state of the sandbox code, does it work, are there any
> >>> >> >> samples,
> >>> >> >> does bigbank run?
> >>> >> >>
> >>> >> >> What is the intention for the future of the sandbox code?
> >>> >> >>
> >>> >> >> It sounds like we're being asked to just go look at some code in
> >>> >> >> the sandbox
> >>> >> >> and work all this out for ourselves. There's a lot of people
> >>> >> >> listening who
> >>> >> >> have no idea whats going on, so some more detailed background
> >>> >> >> information
> >>> >> >> would really help.
> >>> >> >>
> >>> >> >> Friday is bad for me I can't make anything much after 9am PDT,
> >>> >> >> same for
> >>> >> >> Mondays after 5:30BST, but i'll fit in with most times any
> >>> >> other day.
> >>> >> >>
> >>> >> >> ...ant
> >>> >> >>
> >>> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
> >>> >> >>>
> >>> >> >>> I am very interested in this, but the short notice also
> >>> >> concerns me.
> >>> >> >>> Can we push this out to at least the end of the week (say
> >>> >> >>> Friday?) or
> >>> >> >>> sometime next week so that more people on the list get a
> >>> >> chance to
> >>> >> >>> find out about it and fit it into their schedules?
> >>> >> >>>
> >>> >> >>> Also, Jim & Jeremy -- if you guys have anything in the way of
> >>> >> >>> explanatory material that you could circulate on the list/wiki
> >>> >> >>> before
> >>> >> >>> the presentation, I think that would be very useful..
> >>> certainly I
> >>> >> >>> could use a little more context to help with my own browsing.
> >>> >> >>>
> >>> >> >>> thanks,
> >>> >> >>> k
> >>> >> >>>
> >>> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>> >> >>> > Jim Marino wrote:
> >>> >> >>> > > Hi,
> >>> >> >>> > >
> >>> >> >>> > > There has been some mention offline of Jeremy and I
> >>> >> providing an
> >>> >> >>> > > overview of changes to the SCA specifications and related
> >>> >> >>> recursive
> >>> >> >>> > > core architecture work going on in the sandbox, perhaps
> >>> >> >>> Wednesday. I'm
> >>> >> >>> > > happy to do this, however, I'm a bit concerned that since
> >>> >> >>> this has
> >>> >> >>> not
> >>> >> >>> > > been brought up on the list interested people may not be
> >>> >> >>> able to
> >>> >> >>> attend
> >>> >> >>> > > on short notice. Also, a time has not been mentioned. I
> >>> >> propose
> >>> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free
> >>> dial-
> >>> >> >>> in,
> >>> >> >>> which
> >>> >> >>> > > will be provided later.
> >>> >> >>> > >
> >>> >> >>> > > If interested people cannot make that time, please speak up
> >>> >> >>> so we can
> >>> >> >>> > > arrange an alternate (please don't hesitate to do so,
> >>> even if
> >>> >> >>> you are
> >>> >> >>> > > the only one).
> >>> >> >>> > >
> >>> >> >>> >
> >>> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or
> >>> >> >>> after.
> >>> >> >>> > --
> >>> >> >>> > Jeremy
> >>> >> >>> >
> >>> >> >>> >
> >>> >> >>>
> >>> >> --------------------------------------------------------------------
> >>> >> >>> -
> >>> >> >>> > To unsubscribe, e-mail: tuscany-dev- unsubscribe@ws.apache.org
> >>> >> >>> > For additional commands, e-mail: tuscany-dev-
> >>> help@ws.apache.org
> >>> >> >>> >
> >>> >> >>> >
> >>> >> >>>
> >>> >> >>>
> >>> >> --------------------------------------------------------------------
> >>> >> >>> -
> >>> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> >> >>> For additional commands, e-mail: tuscany-dev- help@ws.apache.org
> >>> >> >>>
> >>> >> >>>
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >>
> >>> ---------------------------------------------------------------------
> >>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >> >
> >>> >>
> >>> >>
> >>> >>
> >>> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > Paul Fremantle
> >>> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >>> >
> >>> > http://bloglines.com/blog/paulfremantle
> >>> > paul@wso2.com
> >>> >
> >>> > "Oxygenating the Web Service Platform", www.wso2.com
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Paul Fremantle
> >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >>
> >> http://bloglines.com/blog/paulfremantle
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Simon Nash <na...@hursley.ibm.com>.
I can think of a couple of options that might work.
1. All Tuscany participants could join the spec collaboration and
get first-hand information on issues and agreed changes.
2. Set up a private Apache mailing list on which non-public spec
information could be distributed and discussions could take place.
I think the second option is better, since it's probably easier for
people not working for members of the collaboration to get on a
private Apache list than to sign up as collaboration members.
This will require agreement from the collaboration team, since it
would open up access to this information to people who have not
signed the formal collaboration agreement. Maybe there could be a
lighter-weight "open source" version of the collaboration agreement
designed for this purpose.
Simon
Jim Marino wrote:
> Good question...
>
> In the spec group, one of the major changes we are currently
> undertaking is a move to a recursive model where components can either
> be leaf-types ("atomic") or composite, in which case they may contain
> children. In previous versions of the spec we had a two-level model
> (module components and components which were leaf-types). The recursive
> model simplifies a great deal since it eliminates a number of
> unnecessary concepts. For example, components used to offer services
> and have references while module components offered entry points and
> had external services. Since there is a common type, component, we can
> dispense with the separate concepts of entry point and external service
> and just call them "service" (~entry point) and "reference" (~external
> service). I think this makes sense from a conceptual standpoint since a
> composite component may have a service bound to some protocol/transport
> combination such as SOAP/HTTP while a service on a POJO may be thought
> of as having a "shared memory"/by- reference binding. Besides making the
> implementation more concise, It also makes slideware easier since we
> have the same picture at different levels :-)
>
> In any event, this was one of the topics we were intending to cover on
> the call.
>
> I think this is a good question specifically because I believe the
> coordination between the spec collaboration and the Tuscany community
> could be a lot better. This partly arises from the fact that the people
> such as myself and Jeremy who wear both hats are swamped with work and
> things sometimes get delayed. Another reason for the less- than-ideal
> situation is that a collaboration model between the spec group and
> Tuscany has not been put in place. Regarding the latter, I believe
> there are some systemic improvements we can make such as not having to
> channel issues through Jeremy or myself as well as having more defined
> input mechanisms between the two groups. The spec group is aware of the
> issue as well so I think it would be fruitful for us to come up with
> some concrete proposals we could discuss with them.
>
> Ideas?
>
> Jim
>
>
> On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
>
>> By the way can someone explain what the term "Recursive Core
>> Architecture" means?
>>
>> Paul
>>
>> On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>> It looks as if we have the choice of Thursday or Friday this week, or
>>> rescheduling for two weeks. I'd prefer we do it this week.
>>>
>>> Jim
>>>
>>> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
>>>
>>> > Next week would be better for me. I'm landing home from the US on
>>> > Friday and 8-10PST is 4-6pm on Friday evening which aint popular in
>>> > blighty :-)
>>> >
>>> > Paul
>>> >
>>> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>>> >> I'm out all next week so it sounds as if Friday is the best time for
>>> >> most people.
>>> >>
>>> >> Jim
>>> >>
>>> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
>>> >>
>>> >> > I like to second all of what Ant wrote and also Ken Tam asked
>>> if it
>>> >> > could not be delayed till next week. I'd like to be up to speed
>>> and
>>> >> > just a few days more would help to digest it all to be more
>>> >> > informed, but I'll go with Friday if that's what it is.
>>> >> > ant elder wrote:
>>> >> >> I agree 100% with Ken, could you give just a little more
>>> >> >> information about
>>> >> >> whats going on here? That email just gives hints - there's been
>>> >> >> some SCA
>>> >> >> spec changes, there's some code in the the sandbox for "recursive
>>> >> >> core
>>> >> >> architecture work" and "to clearly demarcate the runtime
>>> extension
>>> >> >> mechanism."
>>> >> >>
>>> >> >> What are the spec changes, are there any new spec documents
>>> people
>>> >> >> can
>>> >> >> review?
>>> >> >>
>>> >> >> Is there anything else that has changed from the M1 release code
>>> >> >> to whats in
>>> >> >> the sandbox?
>>> >> >>
>>> >> >> Whats the state of the sandbox code, does it work, are there any
>>> >> >> samples,
>>> >> >> does bigbank run?
>>> >> >>
>>> >> >> What is the intention for the future of the sandbox code?
>>> >> >>
>>> >> >> It sounds like we're being asked to just go look at some code in
>>> >> >> the sandbox
>>> >> >> and work all this out for ourselves. There's a lot of people
>>> >> >> listening who
>>> >> >> have no idea whats going on, so some more detailed background
>>> >> >> information
>>> >> >> would really help.
>>> >> >>
>>> >> >> Friday is bad for me I can't make anything much after 9am PDT,
>>> >> >> same for
>>> >> >> Mondays after 5:30BST, but i'll fit in with most times any
>>> >> other day.
>>> >> >>
>>> >> >> ...ant
>>> >> >>
>>> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>>> >> >>>
>>> >> >>> I am very interested in this, but the short notice also
>>> >> concerns me.
>>> >> >>> Can we push this out to at least the end of the week (say
>>> >> >>> Friday?) or
>>> >> >>> sometime next week so that more people on the list get a
>>> >> chance to
>>> >> >>> find out about it and fit it into their schedules?
>>> >> >>>
>>> >> >>> Also, Jim & Jeremy -- if you guys have anything in the way of
>>> >> >>> explanatory material that you could circulate on the list/wiki
>>> >> >>> before
>>> >> >>> the presentation, I think that would be very useful..
>>> certainly I
>>> >> >>> could use a little more context to help with my own browsing.
>>> >> >>>
>>> >> >>> thanks,
>>> >> >>> k
>>> >> >>>
>>> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>>> >> >>> > Jim Marino wrote:
>>> >> >>> > > Hi,
>>> >> >>> > >
>>> >> >>> > > There has been some mention offline of Jeremy and I
>>> >> providing an
>>> >> >>> > > overview of changes to the SCA specifications and related
>>> >> >>> recursive
>>> >> >>> > > core architecture work going on in the sandbox, perhaps
>>> >> >>> Wednesday. I'm
>>> >> >>> > > happy to do this, however, I'm a bit concerned that since
>>> >> >>> this has
>>> >> >>> not
>>> >> >>> > > been brought up on the list interested people may not be
>>> >> >>> able to
>>> >> >>> attend
>>> >> >>> > > on short notice. Also, a time has not been mentioned. I
>>> >> propose
>>> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free
>>> dial-
>>> >> >>> in,
>>> >> >>> which
>>> >> >>> > > will be provided later.
>>> >> >>> > >
>>> >> >>> > > If interested people cannot make that time, please speak up
>>> >> >>> so we can
>>> >> >>> > > arrange an alternate (please don't hesitate to do so,
>>> even if
>>> >> >>> you are
>>> >> >>> > > the only one).
>>> >> >>> > >
>>> >> >>> >
>>> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or
>>> >> >>> after.
>>> >> >>> > --
>>> >> >>> > Jeremy
>>> >> >>> >
>>> >> >>> >
>>> >> >>>
>>> >> --------------------------------------------------------------------
>>> >> >>> -
>>> >> >>> > To unsubscribe, e-mail: tuscany-dev- unsubscribe@ws.apache.org
>>> >> >>> > For additional commands, e-mail: tuscany-dev-
>>> help@ws.apache.org
>>> >> >>> >
>>> >> >>> >
>>> >> >>>
>>> >> >>>
>>> >> --------------------------------------------------------------------
>>> >> >>> -
>>> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> >> >>> For additional commands, e-mail: tuscany-dev- help@ws.apache.org
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >> >
>>> >>
>>> >>
>>> >>
>>> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Paul Fremantle
>>> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>>> >
>>> > http://bloglines.com/blog/paulfremantle
>>> > paul@wso2.com
>>> >
>>> > "Oxygenating the Web Service Platform", www.wso2.com
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>> Paul Fremantle
>> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>>
>> http://bloglines.com/blog/paulfremantle
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Mike Edwards <mi...@gmail.com>.
Paul,
I'll try to spell out the way that the SCA Specification
collaboration works and the IP rules that apply. I'll
do this in a post following from Mike Rowley's note on
"Project IP...."
Yours, Mike.
Paul Fremantle wrote:
> Jim
>
> I understand the IP and Royalty requirements of the published spec.
> But what I don't understand is the IP and Royalty requirements of what
> you refer to as the "spec group". I couldn't find anything on
> osoa.org.
>
> You talk about greater collaboration between the spec group and the
> tuscany group, and one of the main purposes of incubation is to sort
> out IP issues. I'm trying to understand what those issues are.
>
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
Jim
I understand the IP and Royalty requirements of the published spec.
But what I don't understand is the IP and Royalty requirements of what
you refer to as the "spec group". I couldn't find anything on
osoa.org.
You talk about greater collaboration between the spec group and the
tuscany group, and one of the main purposes of incubation is to sort
out IP issues. I'm trying to understand what those issues are.
Paul
On 6/7/06, Jim Marino <jm...@myromatours.com> wrote:
> The IP is royalty free and the license is printed in the body of the
> specifications. The specifications can be found at members'
> sites,e.g. http://dev2dev.bea.com/pub/a/2005/11/sca.html. On
> membership, I'm copying Mike Edwards since he is better at explaining
> that process than myself.
>
>
> Jim
>
>
> On Jun 7, 2006, at 7:22 AM, Paul Fremantle wrote:
>
> > Jim
> >
> > That's very interesting. It sounds similar to some work going on in
> > Synapse where we have a recursive composition model.
> >
> > I think one of the key questions in forging greater links between
> > Tuscany and the spec group is what the IP and membership regulations
> > around the spec group?
> >
> > Is there a web page you can point me at that outlines those?
> >
> > Paul
> >
> >
> >
> > On 6/7/06, Jim Marino <jm...@myromatours.com> wrote:
> >> Good question...
> >>
> >> In the spec group, one of the major changes we are currently
> >> undertaking is a move to a recursive model where components can
> >> either be leaf-types ("atomic") or composite, in which case they may
> >> contain children. In previous versions of the spec we had a two-level
> >> model (module components and components which were leaf-types). The
> >> recursive model simplifies a great deal since it eliminates a number
> >> of unnecessary concepts. For example, components used to offer
> >> services and have references while module components offered entry
> >> points and had external services. Since there is a common type,
> >> component, we can dispense with the separate concepts of entry point
> >> and external service and just call them "service" (~entry point) and
> >> "reference" (~external service). I think this makes sense from a
> >> conceptual standpoint since a composite component may have a service
> >> bound to some protocol/transport combination such as SOAP/HTTP while
> >> a service on a POJO may be thought of as having a "shared memory"/by-
> >> reference binding. Besides making the implementation more concise, It
> >> also makes slideware easier since we have the same picture at
> >> different levels :-)
> >>
> >> In any event, this was one of the topics we were intending to cover
> >> on the call.
> >>
> >> I think this is a good question specifically because I believe the
> >> coordination between the spec collaboration and the Tuscany community
> >> could be a lot better. This partly arises from the fact that the
> >> people such as myself and Jeremy who wear both hats are swamped with
> >> work and things sometimes get delayed. Another reason for the less-
> >> than-ideal situation is that a collaboration model between the spec
> >> group and Tuscany has not been put in place. Regarding the latter, I
> >> believe there are some systemic improvements we can make such as not
> >> having to channel issues through Jeremy or myself as well as having
> >> more defined input mechanisms between the two groups. The spec group
> >> is aware of the issue as well so I think it would be fruitful for us
> >> to come up with some concrete proposals we could discuss with them.
> >>
> >> Ideas?
> >>
> >> Jim
> >>
> >>
> >> On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
> >>
> >> > By the way can someone explain what the term "Recursive Core
> >> > Architecture" means?
> >> >
> >> > Paul
> >> >
> >> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> It looks as if we have the choice of Thursday or Friday this
> >> week, or
> >> >> rescheduling for two weeks. I'd prefer we do it this week.
> >> >>
> >> >> Jim
> >> >>
> >> >> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
> >> >>
> >> >> > Next week would be better for me. I'm landing home from the
> >> US on
> >> >> > Friday and 8-10PST is 4-6pm on Friday evening which aint
> >> popular in
> >> >> > blighty :-)
> >> >> >
> >> >> > Paul
> >> >> >
> >> >> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> >> I'm out all next week so it sounds as if Friday is the best
> >> >> time for
> >> >> >> most people.
> >> >> >>
> >> >> >> Jim
> >> >> >>
> >> >> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
> >> >> >>
> >> >> >> > I like to second all of what Ant wrote and also Ken Tam asked
> >> >> if it
> >> >> >> > could not be delayed till next week. I'd like to be up to
> >> >> speed and
> >> >> >> > just a few days more would help to digest it all to be more
> >> >> >> > informed, but I'll go with Friday if that's what it is.
> >> >> >> > ant elder wrote:
> >> >> >> >> I agree 100% with Ken, could you give just a little more
> >> >> >> >> information about
> >> >> >> >> whats going on here? That email just gives hints -
> >> there's been
> >> >> >> >> some SCA
> >> >> >> >> spec changes, there's some code in the the sandbox for
> >> >> "recursive
> >> >> >> >> core
> >> >> >> >> architecture work" and "to clearly demarcate the runtime
> >> >> extension
> >> >> >> >> mechanism."
> >> >> >> >>
> >> >> >> >> What are the spec changes, are there any new spec documents
> >> >> people
> >> >> >> >> can
> >> >> >> >> review?
> >> >> >> >>
> >> >> >> >> Is there anything else that has changed from the M1 release
> >> >> code
> >> >> >> >> to whats in
> >> >> >> >> the sandbox?
> >> >> >> >>
> >> >> >> >> Whats the state of the sandbox code, does it work, are there
> >> >> any
> >> >> >> >> samples,
> >> >> >> >> does bigbank run?
> >> >> >> >>
> >> >> >> >> What is the intention for the future of the sandbox code?
> >> >> >> >>
> >> >> >> >> It sounds like we're being asked to just go look at some
> >> >> code in
> >> >> >> >> the sandbox
> >> >> >> >> and work all this out for ourselves. There's a lot of people
> >> >> >> >> listening who
> >> >> >> >> have no idea whats going on, so some more detailed
> >> background
> >> >> >> >> information
> >> >> >> >> would really help.
> >> >> >> >>
> >> >> >> >> Friday is bad for me I can't make anything much after 9am
> >> PDT,
> >> >> >> >> same for
> >> >> >> >> Mondays after 5:30BST, but i'll fit in with most times any
> >> >> >> other day.
> >> >> >> >>
> >> >> >> >> ...ant
> >> >> >> >>
> >> >> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
> >> >> >> >>>
> >> >> >> >>> I am very interested in this, but the short notice also
> >> >> >> concerns me.
> >> >> >> >>> Can we push this out to at least the end of the week (say
> >> >> >> >>> Friday?) or
> >> >> >> >>> sometime next week so that more people on the list get a
> >> >> >> chance to
> >> >> >> >>> find out about it and fit it into their schedules?
> >> >> >> >>>
> >> >> >> >>> Also, Jim & Jeremy -- if you guys have anything in the
> >> way of
> >> >> >> >>> explanatory material that you could circulate on the
> >> list/wiki
> >> >> >> >>> before
> >> >> >> >>> the presentation, I think that would be very useful..
> >> >> certainly I
> >> >> >> >>> could use a little more context to help with my own
> >> browsing.
> >> >> >> >>>
> >> >> >> >>> thanks,
> >> >> >> >>> k
> >> >> >> >>>
> >> >> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> >> >> >>> > Jim Marino wrote:
> >> >> >> >>> > > Hi,
> >> >> >> >>> > >
> >> >> >> >>> > > There has been some mention offline of Jeremy and I
> >> >> >> providing an
> >> >> >> >>> > > overview of changes to the SCA specifications and
> >> related
> >> >> >> >>> recursive
> >> >> >> >>> > > core architecture work going on in the sandbox, perhaps
> >> >> >> >>> Wednesday. I'm
> >> >> >> >>> > > happy to do this, however, I'm a bit concerned that
> >> since
> >> >> >> >>> this has
> >> >> >> >>> not
> >> >> >> >>> > > been brought up on the list interested people may
> >> not be
> >> >> >> >>> able to
> >> >> >> >>> attend
> >> >> >> >>> > > on short notice. Also, a time has not been mentioned. I
> >> >> >> propose
> >> >> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free
> >> >> dial-
> >> >> >> >>> in,
> >> >> >> >>> which
> >> >> >> >>> > > will be provided later.
> >> >> >> >>> > >
> >> >> >> >>> > > If interested people cannot make that time, please
> >> >> speak up
> >> >> >> >>> so we can
> >> >> >> >>> > > arrange an alternate (please don't hesitate to do so,
> >> >> even if
> >> >> >> >>> you are
> >> >> >> >>> > > the only one).
> >> >> >> >>> > >
> >> >> >> >>> >
> >> >> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do
> >> >> before or
> >> >> >> >>> after.
> >> >> >> >>> > --
> >> >> >> >>> > Jeremy
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >>
> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >>> -
> >> >> >> >>> > To unsubscribe, e-mail: tuscany-dev-
> >> >> unsubscribe@ws.apache.org
> >> >> >> >>> > For additional commands, e-mail: tuscany-dev-
> >> >> help@ws.apache.org
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>>
> >> >> >>
> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >>> -
> >> >> >> >>> To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >> >> >>> For additional commands, e-mail: tuscany-dev-
> >> >> help@ws.apache.org
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> > For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Paul Fremantle
> >> >> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >> >> >
> >> >> > http://bloglines.com/blog/paulfremantle
> >> >> > paul@wso2.com
> >> >> >
> >> >> > "Oxygenating the Web Service Platform", www.wso2.com
> >> >> >
> >> >> >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Paul Fremantle
> >> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >> >
> >> > http://bloglines.com/blog/paulfremantle
> >> > paul@wso2.com
> >> >
> >> > "Oxygenating the Web Service Platform", www.wso2.com
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
The IP is royalty free and the license is printed in the body of the
specifications. The specifications can be found at members'
sites,e.g. http://dev2dev.bea.com/pub/a/2005/11/sca.html. On
membership, I'm copying Mike Edwards since he is better at explaining
that process than myself.
Jim
On Jun 7, 2006, at 7:22 AM, Paul Fremantle wrote:
> Jim
>
> That's very interesting. It sounds similar to some work going on in
> Synapse where we have a recursive composition model.
>
> I think one of the key questions in forging greater links between
> Tuscany and the spec group is what the IP and membership regulations
> around the spec group?
>
> Is there a web page you can point me at that outlines those?
>
> Paul
>
>
>
> On 6/7/06, Jim Marino <jm...@myromatours.com> wrote:
>> Good question...
>>
>> In the spec group, one of the major changes we are currently
>> undertaking is a move to a recursive model where components can
>> either be leaf-types ("atomic") or composite, in which case they may
>> contain children. In previous versions of the spec we had a two-level
>> model (module components and components which were leaf-types). The
>> recursive model simplifies a great deal since it eliminates a number
>> of unnecessary concepts. For example, components used to offer
>> services and have references while module components offered entry
>> points and had external services. Since there is a common type,
>> component, we can dispense with the separate concepts of entry point
>> and external service and just call them "service" (~entry point) and
>> "reference" (~external service). I think this makes sense from a
>> conceptual standpoint since a composite component may have a service
>> bound to some protocol/transport combination such as SOAP/HTTP while
>> a service on a POJO may be thought of as having a "shared memory"/by-
>> reference binding. Besides making the implementation more concise, It
>> also makes slideware easier since we have the same picture at
>> different levels :-)
>>
>> In any event, this was one of the topics we were intending to cover
>> on the call.
>>
>> I think this is a good question specifically because I believe the
>> coordination between the spec collaboration and the Tuscany community
>> could be a lot better. This partly arises from the fact that the
>> people such as myself and Jeremy who wear both hats are swamped with
>> work and things sometimes get delayed. Another reason for the less-
>> than-ideal situation is that a collaboration model between the spec
>> group and Tuscany has not been put in place. Regarding the latter, I
>> believe there are some systemic improvements we can make such as not
>> having to channel issues through Jeremy or myself as well as having
>> more defined input mechanisms between the two groups. The spec group
>> is aware of the issue as well so I think it would be fruitful for us
>> to come up with some concrete proposals we could discuss with them.
>>
>> Ideas?
>>
>> Jim
>>
>>
>> On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
>>
>> > By the way can someone explain what the term "Recursive Core
>> > Architecture" means?
>> >
>> > Paul
>> >
>> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> It looks as if we have the choice of Thursday or Friday this
>> week, or
>> >> rescheduling for two weeks. I'd prefer we do it this week.
>> >>
>> >> Jim
>> >>
>> >> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
>> >>
>> >> > Next week would be better for me. I'm landing home from the
>> US on
>> >> > Friday and 8-10PST is 4-6pm on Friday evening which aint
>> popular in
>> >> > blighty :-)
>> >> >
>> >> > Paul
>> >> >
>> >> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >> I'm out all next week so it sounds as if Friday is the best
>> >> time for
>> >> >> most people.
>> >> >>
>> >> >> Jim
>> >> >>
>> >> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
>> >> >>
>> >> >> > I like to second all of what Ant wrote and also Ken Tam asked
>> >> if it
>> >> >> > could not be delayed till next week. I'd like to be up to
>> >> speed and
>> >> >> > just a few days more would help to digest it all to be more
>> >> >> > informed, but I'll go with Friday if that's what it is.
>> >> >> > ant elder wrote:
>> >> >> >> I agree 100% with Ken, could you give just a little more
>> >> >> >> information about
>> >> >> >> whats going on here? That email just gives hints -
>> there's been
>> >> >> >> some SCA
>> >> >> >> spec changes, there's some code in the the sandbox for
>> >> "recursive
>> >> >> >> core
>> >> >> >> architecture work" and "to clearly demarcate the runtime
>> >> extension
>> >> >> >> mechanism."
>> >> >> >>
>> >> >> >> What are the spec changes, are there any new spec documents
>> >> people
>> >> >> >> can
>> >> >> >> review?
>> >> >> >>
>> >> >> >> Is there anything else that has changed from the M1 release
>> >> code
>> >> >> >> to whats in
>> >> >> >> the sandbox?
>> >> >> >>
>> >> >> >> Whats the state of the sandbox code, does it work, are there
>> >> any
>> >> >> >> samples,
>> >> >> >> does bigbank run?
>> >> >> >>
>> >> >> >> What is the intention for the future of the sandbox code?
>> >> >> >>
>> >> >> >> It sounds like we're being asked to just go look at some
>> >> code in
>> >> >> >> the sandbox
>> >> >> >> and work all this out for ourselves. There's a lot of people
>> >> >> >> listening who
>> >> >> >> have no idea whats going on, so some more detailed
>> background
>> >> >> >> information
>> >> >> >> would really help.
>> >> >> >>
>> >> >> >> Friday is bad for me I can't make anything much after 9am
>> PDT,
>> >> >> >> same for
>> >> >> >> Mondays after 5:30BST, but i'll fit in with most times any
>> >> >> other day.
>> >> >> >>
>> >> >> >> ...ant
>> >> >> >>
>> >> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>> >> >> >>>
>> >> >> >>> I am very interested in this, but the short notice also
>> >> >> concerns me.
>> >> >> >>> Can we push this out to at least the end of the week (say
>> >> >> >>> Friday?) or
>> >> >> >>> sometime next week so that more people on the list get a
>> >> >> chance to
>> >> >> >>> find out about it and fit it into their schedules?
>> >> >> >>>
>> >> >> >>> Also, Jim & Jeremy -- if you guys have anything in the
>> way of
>> >> >> >>> explanatory material that you could circulate on the
>> list/wiki
>> >> >> >>> before
>> >> >> >>> the presentation, I think that would be very useful..
>> >> certainly I
>> >> >> >>> could use a little more context to help with my own
>> browsing.
>> >> >> >>>
>> >> >> >>> thanks,
>> >> >> >>> k
>> >> >> >>>
>> >> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> >> >> >>> > Jim Marino wrote:
>> >> >> >>> > > Hi,
>> >> >> >>> > >
>> >> >> >>> > > There has been some mention offline of Jeremy and I
>> >> >> providing an
>> >> >> >>> > > overview of changes to the SCA specifications and
>> related
>> >> >> >>> recursive
>> >> >> >>> > > core architecture work going on in the sandbox, perhaps
>> >> >> >>> Wednesday. I'm
>> >> >> >>> > > happy to do this, however, I'm a bit concerned that
>> since
>> >> >> >>> this has
>> >> >> >>> not
>> >> >> >>> > > been brought up on the list interested people may
>> not be
>> >> >> >>> able to
>> >> >> >>> attend
>> >> >> >>> > > on short notice. Also, a time has not been mentioned. I
>> >> >> propose
>> >> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free
>> >> dial-
>> >> >> >>> in,
>> >> >> >>> which
>> >> >> >>> > > will be provided later.
>> >> >> >>> > >
>> >> >> >>> > > If interested people cannot make that time, please
>> >> speak up
>> >> >> >>> so we can
>> >> >> >>> > > arrange an alternate (please don't hesitate to do so,
>> >> even if
>> >> >> >>> you are
>> >> >> >>> > > the only one).
>> >> >> >>> > >
>> >> >> >>> >
>> >> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do
>> >> before or
>> >> >> >>> after.
>> >> >> >>> > --
>> >> >> >>> > Jeremy
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >>
>> >>
>> --------------------------------------------------------------------
>> >> >> >>> -
>> >> >> >>> > To unsubscribe, e-mail: tuscany-dev-
>> >> unsubscribe@ws.apache.org
>> >> >> >>> > For additional commands, e-mail: tuscany-dev-
>> >> help@ws.apache.org
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>>
>> >> >>
>> >>
>> --------------------------------------------------------------------
>> >> >> >>> -
>> >> >> >>> To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >> >> >>> For additional commands, e-mail: tuscany-dev-
>> >> help@ws.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Paul Fremantle
>> >> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>> >> >
>> >> > http://bloglines.com/blog/paulfremantle
>> >> > paul@wso2.com
>> >> >
>> >> > "Oxygenating the Web Service Platform", www.wso2.com
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Paul Fremantle
>> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>> >
>> > http://bloglines.com/blog/paulfremantle
>> > paul@wso2.com
>> >
>> > "Oxygenating the Web Service Platform", www.wso2.com
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
Jim
That's very interesting. It sounds similar to some work going on in
Synapse where we have a recursive composition model.
I think one of the key questions in forging greater links between
Tuscany and the spec group is what the IP and membership regulations
around the spec group?
Is there a web page you can point me at that outlines those?
Paul
On 6/7/06, Jim Marino <jm...@myromatours.com> wrote:
> Good question...
>
> In the spec group, one of the major changes we are currently
> undertaking is a move to a recursive model where components can
> either be leaf-types ("atomic") or composite, in which case they may
> contain children. In previous versions of the spec we had a two-level
> model (module components and components which were leaf-types). The
> recursive model simplifies a great deal since it eliminates a number
> of unnecessary concepts. For example, components used to offer
> services and have references while module components offered entry
> points and had external services. Since there is a common type,
> component, we can dispense with the separate concepts of entry point
> and external service and just call them "service" (~entry point) and
> "reference" (~external service). I think this makes sense from a
> conceptual standpoint since a composite component may have a service
> bound to some protocol/transport combination such as SOAP/HTTP while
> a service on a POJO may be thought of as having a "shared memory"/by-
> reference binding. Besides making the implementation more concise, It
> also makes slideware easier since we have the same picture at
> different levels :-)
>
> In any event, this was one of the topics we were intending to cover
> on the call.
>
> I think this is a good question specifically because I believe the
> coordination between the spec collaboration and the Tuscany community
> could be a lot better. This partly arises from the fact that the
> people such as myself and Jeremy who wear both hats are swamped with
> work and things sometimes get delayed. Another reason for the less-
> than-ideal situation is that a collaboration model between the spec
> group and Tuscany has not been put in place. Regarding the latter, I
> believe there are some systemic improvements we can make such as not
> having to channel issues through Jeremy or myself as well as having
> more defined input mechanisms between the two groups. The spec group
> is aware of the issue as well so I think it would be fruitful for us
> to come up with some concrete proposals we could discuss with them.
>
> Ideas?
>
> Jim
>
>
> On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
>
> > By the way can someone explain what the term "Recursive Core
> > Architecture" means?
> >
> > Paul
> >
> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> It looks as if we have the choice of Thursday or Friday this week, or
> >> rescheduling for two weeks. I'd prefer we do it this week.
> >>
> >> Jim
> >>
> >> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
> >>
> >> > Next week would be better for me. I'm landing home from the US on
> >> > Friday and 8-10PST is 4-6pm on Friday evening which aint popular in
> >> > blighty :-)
> >> >
> >> > Paul
> >> >
> >> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> I'm out all next week so it sounds as if Friday is the best
> >> time for
> >> >> most people.
> >> >>
> >> >> Jim
> >> >>
> >> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
> >> >>
> >> >> > I like to second all of what Ant wrote and also Ken Tam asked
> >> if it
> >> >> > could not be delayed till next week. I'd like to be up to
> >> speed and
> >> >> > just a few days more would help to digest it all to be more
> >> >> > informed, but I'll go with Friday if that's what it is.
> >> >> > ant elder wrote:
> >> >> >> I agree 100% with Ken, could you give just a little more
> >> >> >> information about
> >> >> >> whats going on here? That email just gives hints - there's been
> >> >> >> some SCA
> >> >> >> spec changes, there's some code in the the sandbox for
> >> "recursive
> >> >> >> core
> >> >> >> architecture work" and "to clearly demarcate the runtime
> >> extension
> >> >> >> mechanism."
> >> >> >>
> >> >> >> What are the spec changes, are there any new spec documents
> >> people
> >> >> >> can
> >> >> >> review?
> >> >> >>
> >> >> >> Is there anything else that has changed from the M1 release
> >> code
> >> >> >> to whats in
> >> >> >> the sandbox?
> >> >> >>
> >> >> >> Whats the state of the sandbox code, does it work, are there
> >> any
> >> >> >> samples,
> >> >> >> does bigbank run?
> >> >> >>
> >> >> >> What is the intention for the future of the sandbox code?
> >> >> >>
> >> >> >> It sounds like we're being asked to just go look at some
> >> code in
> >> >> >> the sandbox
> >> >> >> and work all this out for ourselves. There's a lot of people
> >> >> >> listening who
> >> >> >> have no idea whats going on, so some more detailed background
> >> >> >> information
> >> >> >> would really help.
> >> >> >>
> >> >> >> Friday is bad for me I can't make anything much after 9am PDT,
> >> >> >> same for
> >> >> >> Mondays after 5:30BST, but i'll fit in with most times any
> >> >> other day.
> >> >> >>
> >> >> >> ...ant
> >> >> >>
> >> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
> >> >> >>>
> >> >> >>> I am very interested in this, but the short notice also
> >> >> concerns me.
> >> >> >>> Can we push this out to at least the end of the week (say
> >> >> >>> Friday?) or
> >> >> >>> sometime next week so that more people on the list get a
> >> >> chance to
> >> >> >>> find out about it and fit it into their schedules?
> >> >> >>>
> >> >> >>> Also, Jim & Jeremy -- if you guys have anything in the way of
> >> >> >>> explanatory material that you could circulate on the list/wiki
> >> >> >>> before
> >> >> >>> the presentation, I think that would be very useful..
> >> certainly I
> >> >> >>> could use a little more context to help with my own browsing.
> >> >> >>>
> >> >> >>> thanks,
> >> >> >>> k
> >> >> >>>
> >> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> >> >>> > Jim Marino wrote:
> >> >> >>> > > Hi,
> >> >> >>> > >
> >> >> >>> > > There has been some mention offline of Jeremy and I
> >> >> providing an
> >> >> >>> > > overview of changes to the SCA specifications and related
> >> >> >>> recursive
> >> >> >>> > > core architecture work going on in the sandbox, perhaps
> >> >> >>> Wednesday. I'm
> >> >> >>> > > happy to do this, however, I'm a bit concerned that since
> >> >> >>> this has
> >> >> >>> not
> >> >> >>> > > been brought up on the list interested people may not be
> >> >> >>> able to
> >> >> >>> attend
> >> >> >>> > > on short notice. Also, a time has not been mentioned. I
> >> >> propose
> >> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free
> >> dial-
> >> >> >>> in,
> >> >> >>> which
> >> >> >>> > > will be provided later.
> >> >> >>> > >
> >> >> >>> > > If interested people cannot make that time, please
> >> speak up
> >> >> >>> so we can
> >> >> >>> > > arrange an alternate (please don't hesitate to do so,
> >> even if
> >> >> >>> you are
> >> >> >>> > > the only one).
> >> >> >>> > >
> >> >> >>> >
> >> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do
> >> before or
> >> >> >>> after.
> >> >> >>> > --
> >> >> >>> > Jeremy
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >>
> >> --------------------------------------------------------------------
> >> >> >>> -
> >> >> >>> > To unsubscribe, e-mail: tuscany-dev-
> >> unsubscribe@ws.apache.org
> >> >> >>> > For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >>
> >> --------------------------------------------------------------------
> >> >> >>> -
> >> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >>> For additional commands, e-mail: tuscany-dev-
> >> help@ws.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Paul Fremantle
> >> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >> >
> >> > http://bloglines.com/blog/paulfremantle
> >> > paul@wso2.com
> >> >
> >> > "Oxygenating the Web Service Platform", www.wso2.com
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
Good question...
In the spec group, one of the major changes we are currently
undertaking is a move to a recursive model where components can
either be leaf-types ("atomic") or composite, in which case they may
contain children. In previous versions of the spec we had a two-level
model (module components and components which were leaf-types). The
recursive model simplifies a great deal since it eliminates a number
of unnecessary concepts. For example, components used to offer
services and have references while module components offered entry
points and had external services. Since there is a common type,
component, we can dispense with the separate concepts of entry point
and external service and just call them "service" (~entry point) and
"reference" (~external service). I think this makes sense from a
conceptual standpoint since a composite component may have a service
bound to some protocol/transport combination such as SOAP/HTTP while
a service on a POJO may be thought of as having a "shared memory"/by-
reference binding. Besides making the implementation more concise, It
also makes slideware easier since we have the same picture at
different levels :-)
In any event, this was one of the topics we were intending to cover
on the call.
I think this is a good question specifically because I believe the
coordination between the spec collaboration and the Tuscany community
could be a lot better. This partly arises from the fact that the
people such as myself and Jeremy who wear both hats are swamped with
work and things sometimes get delayed. Another reason for the less-
than-ideal situation is that a collaboration model between the spec
group and Tuscany has not been put in place. Regarding the latter, I
believe there are some systemic improvements we can make such as not
having to channel issues through Jeremy or myself as well as having
more defined input mechanisms between the two groups. The spec group
is aware of the issue as well so I think it would be fruitful for us
to come up with some concrete proposals we could discuss with them.
Ideas?
Jim
On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
> By the way can someone explain what the term "Recursive Core
> Architecture" means?
>
> Paul
>
> On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> It looks as if we have the choice of Thursday or Friday this week, or
>> rescheduling for two weeks. I'd prefer we do it this week.
>>
>> Jim
>>
>> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
>>
>> > Next week would be better for me. I'm landing home from the US on
>> > Friday and 8-10PST is 4-6pm on Friday evening which aint popular in
>> > blighty :-)
>> >
>> > Paul
>> >
>> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> I'm out all next week so it sounds as if Friday is the best
>> time for
>> >> most people.
>> >>
>> >> Jim
>> >>
>> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
>> >>
>> >> > I like to second all of what Ant wrote and also Ken Tam asked
>> if it
>> >> > could not be delayed till next week. I'd like to be up to
>> speed and
>> >> > just a few days more would help to digest it all to be more
>> >> > informed, but I'll go with Friday if that's what it is.
>> >> > ant elder wrote:
>> >> >> I agree 100% with Ken, could you give just a little more
>> >> >> information about
>> >> >> whats going on here? That email just gives hints - there's been
>> >> >> some SCA
>> >> >> spec changes, there's some code in the the sandbox for
>> "recursive
>> >> >> core
>> >> >> architecture work" and "to clearly demarcate the runtime
>> extension
>> >> >> mechanism."
>> >> >>
>> >> >> What are the spec changes, are there any new spec documents
>> people
>> >> >> can
>> >> >> review?
>> >> >>
>> >> >> Is there anything else that has changed from the M1 release
>> code
>> >> >> to whats in
>> >> >> the sandbox?
>> >> >>
>> >> >> Whats the state of the sandbox code, does it work, are there
>> any
>> >> >> samples,
>> >> >> does bigbank run?
>> >> >>
>> >> >> What is the intention for the future of the sandbox code?
>> >> >>
>> >> >> It sounds like we're being asked to just go look at some
>> code in
>> >> >> the sandbox
>> >> >> and work all this out for ourselves. There's a lot of people
>> >> >> listening who
>> >> >> have no idea whats going on, so some more detailed background
>> >> >> information
>> >> >> would really help.
>> >> >>
>> >> >> Friday is bad for me I can't make anything much after 9am PDT,
>> >> >> same for
>> >> >> Mondays after 5:30BST, but i'll fit in with most times any
>> >> other day.
>> >> >>
>> >> >> ...ant
>> >> >>
>> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>> >> >>>
>> >> >>> I am very interested in this, but the short notice also
>> >> concerns me.
>> >> >>> Can we push this out to at least the end of the week (say
>> >> >>> Friday?) or
>> >> >>> sometime next week so that more people on the list get a
>> >> chance to
>> >> >>> find out about it and fit it into their schedules?
>> >> >>>
>> >> >>> Also, Jim & Jeremy -- if you guys have anything in the way of
>> >> >>> explanatory material that you could circulate on the list/wiki
>> >> >>> before
>> >> >>> the presentation, I think that would be very useful..
>> certainly I
>> >> >>> could use a little more context to help with my own browsing.
>> >> >>>
>> >> >>> thanks,
>> >> >>> k
>> >> >>>
>> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> >> >>> > Jim Marino wrote:
>> >> >>> > > Hi,
>> >> >>> > >
>> >> >>> > > There has been some mention offline of Jeremy and I
>> >> providing an
>> >> >>> > > overview of changes to the SCA specifications and related
>> >> >>> recursive
>> >> >>> > > core architecture work going on in the sandbox, perhaps
>> >> >>> Wednesday. I'm
>> >> >>> > > happy to do this, however, I'm a bit concerned that since
>> >> >>> this has
>> >> >>> not
>> >> >>> > > been brought up on the list interested people may not be
>> >> >>> able to
>> >> >>> attend
>> >> >>> > > on short notice. Also, a time has not been mentioned. I
>> >> propose
>> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free
>> dial-
>> >> >>> in,
>> >> >>> which
>> >> >>> > > will be provided later.
>> >> >>> > >
>> >> >>> > > If interested people cannot make that time, please
>> speak up
>> >> >>> so we can
>> >> >>> > > arrange an alternate (please don't hesitate to do so,
>> even if
>> >> >>> you are
>> >> >>> > > the only one).
>> >> >>> > >
>> >> >>> >
>> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do
>> before or
>> >> >>> after.
>> >> >>> > --
>> >> >>> > Jeremy
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >>
>> --------------------------------------------------------------------
>> >> >>> -
>> >> >>> > To unsubscribe, e-mail: tuscany-dev-
>> unsubscribe@ws.apache.org
>> >> >>> > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> >>
>> --------------------------------------------------------------------
>> >> >>> -
>> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> >>> For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Paul Fremantle
>> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>> >
>> > http://bloglines.com/blog/paulfremantle
>> > paul@wso2.com
>> >
>> > "Oxygenating the Web Service Platform", www.wso2.com
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
By the way can someone explain what the term "Recursive Core
Architecture" means?
Paul
On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> It looks as if we have the choice of Thursday or Friday this week, or
> rescheduling for two weeks. I'd prefer we do it this week.
>
> Jim
>
> On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
>
> > Next week would be better for me. I'm landing home from the US on
> > Friday and 8-10PST is 4-6pm on Friday evening which aint popular in
> > blighty :-)
> >
> > Paul
> >
> > On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> I'm out all next week so it sounds as if Friday is the best time for
> >> most people.
> >>
> >> Jim
> >>
> >> On Jun 6, 2006, at 10:42 AM, Rick wrote:
> >>
> >> > I like to second all of what Ant wrote and also Ken Tam asked if it
> >> > could not be delayed till next week. I'd like to be up to speed and
> >> > just a few days more would help to digest it all to be more
> >> > informed, but I'll go with Friday if that's what it is.
> >> > ant elder wrote:
> >> >> I agree 100% with Ken, could you give just a little more
> >> >> information about
> >> >> whats going on here? That email just gives hints - there's been
> >> >> some SCA
> >> >> spec changes, there's some code in the the sandbox for "recursive
> >> >> core
> >> >> architecture work" and "to clearly demarcate the runtime extension
> >> >> mechanism."
> >> >>
> >> >> What are the spec changes, are there any new spec documents people
> >> >> can
> >> >> review?
> >> >>
> >> >> Is there anything else that has changed from the M1 release code
> >> >> to whats in
> >> >> the sandbox?
> >> >>
> >> >> Whats the state of the sandbox code, does it work, are there any
> >> >> samples,
> >> >> does bigbank run?
> >> >>
> >> >> What is the intention for the future of the sandbox code?
> >> >>
> >> >> It sounds like we're being asked to just go look at some code in
> >> >> the sandbox
> >> >> and work all this out for ourselves. There's a lot of people
> >> >> listening who
> >> >> have no idea whats going on, so some more detailed background
> >> >> information
> >> >> would really help.
> >> >>
> >> >> Friday is bad for me I can't make anything much after 9am PDT,
> >> >> same for
> >> >> Mondays after 5:30BST, but i'll fit in with most times any
> >> other day.
> >> >>
> >> >> ...ant
> >> >>
> >> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
> >> >>>
> >> >>> I am very interested in this, but the short notice also
> >> concerns me.
> >> >>> Can we push this out to at least the end of the week (say
> >> >>> Friday?) or
> >> >>> sometime next week so that more people on the list get a
> >> chance to
> >> >>> find out about it and fit it into their schedules?
> >> >>>
> >> >>> Also, Jim & Jeremy -- if you guys have anything in the way of
> >> >>> explanatory material that you could circulate on the list/wiki
> >> >>> before
> >> >>> the presentation, I think that would be very useful.. certainly I
> >> >>> could use a little more context to help with my own browsing.
> >> >>>
> >> >>> thanks,
> >> >>> k
> >> >>>
> >> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> >>> > Jim Marino wrote:
> >> >>> > > Hi,
> >> >>> > >
> >> >>> > > There has been some mention offline of Jeremy and I
> >> providing an
> >> >>> > > overview of changes to the SCA specifications and related
> >> >>> recursive
> >> >>> > > core architecture work going on in the sandbox, perhaps
> >> >>> Wednesday. I'm
> >> >>> > > happy to do this, however, I'm a bit concerned that since
> >> >>> this has
> >> >>> not
> >> >>> > > been brought up on the list interested people may not be
> >> >>> able to
> >> >>> attend
> >> >>> > > on short notice. Also, a time has not been mentioned. I
> >> propose
> >> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free dial-
> >> >>> in,
> >> >>> which
> >> >>> > > will be provided later.
> >> >>> > >
> >> >>> > > If interested people cannot make that time, please speak up
> >> >>> so we can
> >> >>> > > arrange an alternate (please don't hesitate to do so, even if
> >> >>> you are
> >> >>> > > the only one).
> >> >>> > >
> >> >>> >
> >> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or
> >> >>> after.
> >> >>> > --
> >> >>> > Jeremy
> >> >>> >
> >> >>> >
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> -
> >> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> -
> >> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
It looks as if we have the choice of Thursday or Friday this week, or
rescheduling for two weeks. I'd prefer we do it this week.
Jim
On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote:
> Next week would be better for me. I'm landing home from the US on
> Friday and 8-10PST is 4-6pm on Friday evening which aint popular in
> blighty :-)
>
> Paul
>
> On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> I'm out all next week so it sounds as if Friday is the best time for
>> most people.
>>
>> Jim
>>
>> On Jun 6, 2006, at 10:42 AM, Rick wrote:
>>
>> > I like to second all of what Ant wrote and also Ken Tam asked if it
>> > could not be delayed till next week. I'd like to be up to speed and
>> > just a few days more would help to digest it all to be more
>> > informed, but I'll go with Friday if that's what it is.
>> > ant elder wrote:
>> >> I agree 100% with Ken, could you give just a little more
>> >> information about
>> >> whats going on here? That email just gives hints - there's been
>> >> some SCA
>> >> spec changes, there's some code in the the sandbox for "recursive
>> >> core
>> >> architecture work" and "to clearly demarcate the runtime extension
>> >> mechanism."
>> >>
>> >> What are the spec changes, are there any new spec documents people
>> >> can
>> >> review?
>> >>
>> >> Is there anything else that has changed from the M1 release code
>> >> to whats in
>> >> the sandbox?
>> >>
>> >> Whats the state of the sandbox code, does it work, are there any
>> >> samples,
>> >> does bigbank run?
>> >>
>> >> What is the intention for the future of the sandbox code?
>> >>
>> >> It sounds like we're being asked to just go look at some code in
>> >> the sandbox
>> >> and work all this out for ourselves. There's a lot of people
>> >> listening who
>> >> have no idea whats going on, so some more detailed background
>> >> information
>> >> would really help.
>> >>
>> >> Friday is bad for me I can't make anything much after 9am PDT,
>> >> same for
>> >> Mondays after 5:30BST, but i'll fit in with most times any
>> other day.
>> >>
>> >> ...ant
>> >>
>> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>> >>>
>> >>> I am very interested in this, but the short notice also
>> concerns me.
>> >>> Can we push this out to at least the end of the week (say
>> >>> Friday?) or
>> >>> sometime next week so that more people on the list get a
>> chance to
>> >>> find out about it and fit it into their schedules?
>> >>>
>> >>> Also, Jim & Jeremy -- if you guys have anything in the way of
>> >>> explanatory material that you could circulate on the list/wiki
>> >>> before
>> >>> the presentation, I think that would be very useful.. certainly I
>> >>> could use a little more context to help with my own browsing.
>> >>>
>> >>> thanks,
>> >>> k
>> >>>
>> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> >>> > Jim Marino wrote:
>> >>> > > Hi,
>> >>> > >
>> >>> > > There has been some mention offline of Jeremy and I
>> providing an
>> >>> > > overview of changes to the SCA specifications and related
>> >>> recursive
>> >>> > > core architecture work going on in the sandbox, perhaps
>> >>> Wednesday. I'm
>> >>> > > happy to do this, however, I'm a bit concerned that since
>> >>> this has
>> >>> not
>> >>> > > been brought up on the list interested people may not be
>> >>> able to
>> >>> attend
>> >>> > > on short notice. Also, a time has not been mentioned. I
>> propose
>> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free dial-
>> >>> in,
>> >>> which
>> >>> > > will be provided later.
>> >>> > >
>> >>> > > If interested people cannot make that time, please speak up
>> >>> so we can
>> >>> > > arrange an alternate (please don't hesitate to do so, even if
>> >>> you are
>> >>> > > the only one).
>> >>> > >
>> >>> >
>> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or
>> >>> after.
>> >>> > --
>> >>> > Jeremy
>> >>> >
>> >>> >
>> >>>
>> --------------------------------------------------------------------
>> >>> -
>> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>>
>> --------------------------------------------------------------------
>> >>> -
>> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Paul Fremantle <pz...@gmail.com>.
Next week would be better for me. I'm landing home from the US on
Friday and 8-10PST is 4-6pm on Friday evening which aint popular in
blighty :-)
Paul
On 6/6/06, Jim Marino <jm...@myromatours.com> wrote:
> I'm out all next week so it sounds as if Friday is the best time for
> most people.
>
> Jim
>
> On Jun 6, 2006, at 10:42 AM, Rick wrote:
>
> > I like to second all of what Ant wrote and also Ken Tam asked if it
> > could not be delayed till next week. I'd like to be up to speed and
> > just a few days more would help to digest it all to be more
> > informed, but I'll go with Friday if that's what it is.
> > ant elder wrote:
> >> I agree 100% with Ken, could you give just a little more
> >> information about
> >> whats going on here? That email just gives hints - there's been
> >> some SCA
> >> spec changes, there's some code in the the sandbox for "recursive
> >> core
> >> architecture work" and "to clearly demarcate the runtime extension
> >> mechanism."
> >>
> >> What are the spec changes, are there any new spec documents people
> >> can
> >> review?
> >>
> >> Is there anything else that has changed from the M1 release code
> >> to whats in
> >> the sandbox?
> >>
> >> Whats the state of the sandbox code, does it work, are there any
> >> samples,
> >> does bigbank run?
> >>
> >> What is the intention for the future of the sandbox code?
> >>
> >> It sounds like we're being asked to just go look at some code in
> >> the sandbox
> >> and work all this out for ourselves. There's a lot of people
> >> listening who
> >> have no idea whats going on, so some more detailed background
> >> information
> >> would really help.
> >>
> >> Friday is bad for me I can't make anything much after 9am PDT,
> >> same for
> >> Mondays after 5:30BST, but i'll fit in with most times any other day.
> >>
> >> ...ant
> >>
> >> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
> >>>
> >>> I am very interested in this, but the short notice also concerns me.
> >>> Can we push this out to at least the end of the week (say
> >>> Friday?) or
> >>> sometime next week so that more people on the list get a chance to
> >>> find out about it and fit it into their schedules?
> >>>
> >>> Also, Jim & Jeremy -- if you guys have anything in the way of
> >>> explanatory material that you could circulate on the list/wiki
> >>> before
> >>> the presentation, I think that would be very useful.. certainly I
> >>> could use a little more context to help with my own browsing.
> >>>
> >>> thanks,
> >>> k
> >>>
> >>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>> > Jim Marino wrote:
> >>> > > Hi,
> >>> > >
> >>> > > There has been some mention offline of Jeremy and I providing an
> >>> > > overview of changes to the SCA specifications and related
> >>> recursive
> >>> > > core architecture work going on in the sandbox, perhaps
> >>> Wednesday. I'm
> >>> > > happy to do this, however, I'm a bit concerned that since
> >>> this has
> >>> not
> >>> > > been brought up on the list interested people may not be
> >>> able to
> >>> attend
> >>> > > on short notice. Also, a time has not been mentioned. I propose
> >>> > > 9PST-11PST, using a combination of Web-Ex and toll-free dial-
> >>> in,
> >>> which
> >>> > > will be provided later.
> >>> > >
> >>> > > If interested people cannot make that time, please speak up
> >>> so we can
> >>> > > arrange an alternate (please don't hesitate to do so, even if
> >>> you are
> >>> > > the only one).
> >>> > >
> >>> >
> >>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or
> >>> after.
> >>> > --
> >>> > Jeremy
> >>> >
> >>> >
> >>> --------------------------------------------------------------------
> >>> -
> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >
> >>> >
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
I'm out all next week so it sounds as if Friday is the best time for
most people.
Jim
On Jun 6, 2006, at 10:42 AM, Rick wrote:
> I like to second all of what Ant wrote and also Ken Tam asked if it
> could not be delayed till next week. I'd like to be up to speed and
> just a few days more would help to digest it all to be more
> informed, but I'll go with Friday if that's what it is.
> ant elder wrote:
>> I agree 100% with Ken, could you give just a little more
>> information about
>> whats going on here? That email just gives hints - there's been
>> some SCA
>> spec changes, there's some code in the the sandbox for "recursive
>> core
>> architecture work" and "to clearly demarcate the runtime extension
>> mechanism."
>>
>> What are the spec changes, are there any new spec documents people
>> can
>> review?
>>
>> Is there anything else that has changed from the M1 release code
>> to whats in
>> the sandbox?
>>
>> Whats the state of the sandbox code, does it work, are there any
>> samples,
>> does bigbank run?
>>
>> What is the intention for the future of the sandbox code?
>>
>> It sounds like we're being asked to just go look at some code in
>> the sandbox
>> and work all this out for ourselves. There's a lot of people
>> listening who
>> have no idea whats going on, so some more detailed background
>> information
>> would really help.
>>
>> Friday is bad for me I can't make anything much after 9am PDT,
>> same for
>> Mondays after 5:30BST, but i'll fit in with most times any other day.
>>
>> ...ant
>>
>> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>>>
>>> I am very interested in this, but the short notice also concerns me.
>>> Can we push this out to at least the end of the week (say
>>> Friday?) or
>>> sometime next week so that more people on the list get a chance to
>>> find out about it and fit it into their schedules?
>>>
>>> Also, Jim & Jeremy -- if you guys have anything in the way of
>>> explanatory material that you could circulate on the list/wiki
>>> before
>>> the presentation, I think that would be very useful.. certainly I
>>> could use a little more context to help with my own browsing.
>>>
>>> thanks,
>>> k
>>>
>>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>>> > Jim Marino wrote:
>>> > > Hi,
>>> > >
>>> > > There has been some mention offline of Jeremy and I providing an
>>> > > overview of changes to the SCA specifications and related
>>> recursive
>>> > > core architecture work going on in the sandbox, perhaps
>>> Wednesday. I'm
>>> > > happy to do this, however, I'm a bit concerned that since
>>> this has
>>> not
>>> > > been brought up on the list interested people may not be
>>> able to
>>> attend
>>> > > on short notice. Also, a time has not been mentioned. I propose
>>> > > 9PST-11PST, using a combination of Web-Ex and toll-free dial-
>>> in,
>>> which
>>> > > will be provided later.
>>> > >
>>> > > If interested people cannot make that time, please speak up
>>> so we can
>>> > > arrange an alternate (please don't hesitate to do so, even if
>>> you are
>>> > > the only one).
>>> > >
>>> >
>>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or
>>> after.
>>> > --
>>> > Jeremy
>>> >
>>> >
>>> --------------------------------------------------------------------
>>> -
>>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>> >
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Rick <cr...@gmail.com>.
I like to second all of what Ant wrote and also Ken Tam asked if it
could not be delayed till next week. I'd like to be up to speed and just
a few days more would help to digest it all to be more informed, but
I'll go with Friday if that's what it is.
ant elder wrote:
> I agree 100% with Ken, could you give just a little more information
> about
> whats going on here? That email just gives hints - there's been some SCA
> spec changes, there's some code in the the sandbox for "recursive core
> architecture work" and "to clearly demarcate the runtime extension
> mechanism."
>
> What are the spec changes, are there any new spec documents people can
> review?
>
> Is there anything else that has changed from the M1 release code to
> whats in
> the sandbox?
>
> Whats the state of the sandbox code, does it work, are there any samples,
> does bigbank run?
>
> What is the intention for the future of the sandbox code?
>
> It sounds like we're being asked to just go look at some code in the
> sandbox
> and work all this out for ourselves. There's a lot of people listening
> who
> have no idea whats going on, so some more detailed background information
> would really help.
>
> Friday is bad for me I can't make anything much after 9am PDT, same for
> Mondays after 5:30BST, but i'll fit in with most times any other day.
>
> ...ant
>
> On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>>
>> I am very interested in this, but the short notice also concerns me.
>> Can we push this out to at least the end of the week (say Friday?) or
>> sometime next week so that more people on the list get a chance to
>> find out about it and fit it into their schedules?
>>
>> Also, Jim & Jeremy -- if you guys have anything in the way of
>> explanatory material that you could circulate on the list/wiki before
>> the presentation, I think that would be very useful.. certainly I
>> could use a little more context to help with my own browsing.
>>
>> thanks,
>> k
>>
>> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> > Jim Marino wrote:
>> > > Hi,
>> > >
>> > > There has been some mention offline of Jeremy and I providing an
>> > > overview of changes to the SCA specifications and related recursive
>> > > core architecture work going on in the sandbox, perhaps
>> Wednesday. I'm
>> > > happy to do this, however, I'm a bit concerned that since this has
>> not
>> > > been brought up on the list interested people may not be able to
>> attend
>> > > on short notice. Also, a time has not been mentioned. I propose
>> > > 9PST-11PST, using a combination of Web-Ex and toll-free dial- in,
>> which
>> > > will be provided later.
>> > >
>> > > If interested people cannot make that time, please speak up so we
>> can
>> > > arrange an alternate (please don't hesitate to do so, even if you
>> are
>> > > the only one).
>> > >
>> >
>> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after.
>> > --
>> > Jeremy
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by ant elder <an...@gmail.com>.
I agree 100% with Ken, could you give just a little more information about
whats going on here? That email just gives hints - there's been some SCA
spec changes, there's some code in the the sandbox for "recursive core
architecture work" and "to clearly demarcate the runtime extension
mechanism."
What are the spec changes, are there any new spec documents people can
review?
Is there anything else that has changed from the M1 release code to whats in
the sandbox?
Whats the state of the sandbox code, does it work, are there any samples,
does bigbank run?
What is the intention for the future of the sandbox code?
It sounds like we're being asked to just go look at some code in the sandbox
and work all this out for ourselves. There's a lot of people listening who
have no idea whats going on, so some more detailed background information
would really help.
Friday is bad for me I can't make anything much after 9am PDT, same for
Mondays after 5:30BST, but i'll fit in with most times any other day.
...ant
On 6/5/06, Kenneth Tam <kentaminator@gmail.com > wrote:
>
> I am very interested in this, but the short notice also concerns me.
> Can we push this out to at least the end of the week (say Friday?) or
> sometime next week so that more people on the list get a chance to
> find out about it and fit it into their schedules?
>
> Also, Jim & Jeremy -- if you guys have anything in the way of
> explanatory material that you could circulate on the list/wiki before
> the presentation, I think that would be very useful.. certainly I
> could use a little more context to help with my own browsing.
>
> thanks,
> k
>
> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> > Jim Marino wrote:
> > > Hi,
> > >
> > > There has been some mention offline of Jeremy and I providing an
> > > overview of changes to the SCA specifications and related recursive
> > > core architecture work going on in the sandbox, perhaps
> Wednesday. I'm
> > > happy to do this, however, I'm a bit concerned that since this has
> not
> > > been brought up on the list interested people may not be able to
> attend
> > > on short notice. Also, a time has not been mentioned. I propose
> > > 9PST-11PST, using a combination of Web-Ex and toll-free dial- in,
> which
> > > will be provided later.
> > >
> > > If interested people cannot make that time, please speak up so we can
> > > arrange an alternate (please don't hesitate to do so, even if you are
> > > the only one).
> > >
> >
> > Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after.
> > --
> > Jeremy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Recursive core architectural overview
Posted by Jim Marino <jm...@myromatours.com>.
Yes this would be appreciated. Can you make sure it's in a common
graphic format - I'm too cheap to shell out the $$ for a UML tool ;-)
Jim
On Jun 5, 2006, at 12:29 PM, Jeremy Boynes wrote:
> Raymond Feng wrote:
>> Hi,
>>
>> I have created some basic slides and UML diagrams when I looked
>> into the
>> sandbox code last week (I need to do some adjustments since more
>> refactorings were checked in). I can upload them into the wiki and
>> Jim/Jeremy can verify to see if it's helpful.
>>
>
> Thanks - that would be appreciated.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Jeremy Boynes <jb...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I have created some basic slides and UML diagrams when I looked into the
> sandbox code last week (I need to do some adjustments since more
> refactorings were checked in). I can upload them into the wiki and
> Jim/Jeremy can verify to see if it's helpful.
>
Thanks - that would be appreciated.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have created some basic slides and UML diagrams when I looked into the
sandbox code last week (I need to do some adjustments since more
refactorings were checked in). I can upload them into the wiki and
Jim/Jeremy can verify to see if it's helpful.
Thanks,
Raymond
----- Original Message -----
From: "Kenneth Tam" <ke...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Monday, June 05, 2006 11:55 AM
Subject: Re: Recursive core architectural overview
>I am very interested in this, but the short notice also concerns me.
> Can we push this out to at least the end of the week (say Friday?) or
> sometime next week so that more people on the list get a chance to
> find out about it and fit it into their schedules?
>
> Also, Jim & Jeremy -- if you guys have anything in the way of
> explanatory material that you could circulate on the list/wiki before
> the presentation, I think that would be very useful.. certainly I
> could use a little more context to help with my own browsing.
>
> thanks,
> k
>
> On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> Jim Marino wrote:
>> > Hi,
>> >
>> > There has been some mention offline of Jeremy and I providing an
>> > overview of changes to the SCA specifications and related recursive
>> > core architecture work going on in the sandbox, perhaps Wednesday. I'm
>> > happy to do this, however, I'm a bit concerned that since this has not
>> > been brought up on the list interested people may not be able to
>> > attend
>> > on short notice. Also, a time has not been mentioned. I propose
>> > 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which
>> > will be provided later.
>> >
>> > If interested people cannot make that time, please speak up so we can
>> > arrange an alternate (please don't hesitate to do so, even if you are
>> > the only one).
>> >
>>
>> Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after.
>> --
>> Jeremy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Recursive core architectural overview
Posted by Kenneth Tam <ke...@gmail.com>.
I am very interested in this, but the short notice also concerns me.
Can we push this out to at least the end of the week (say Friday?) or
sometime next week so that more people on the list get a chance to
find out about it and fit it into their schedules?
Also, Jim & Jeremy -- if you guys have anything in the way of
explanatory material that you could circulate on the list/wiki before
the presentation, I think that would be very useful.. certainly I
could use a little more context to help with my own browsing.
thanks,
k
On 6/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> Jim Marino wrote:
> > Hi,
> >
> > There has been some mention offline of Jeremy and I providing an
> > overview of changes to the SCA specifications and related recursive
> > core architecture work going on in the sandbox, perhaps Wednesday. I'm
> > happy to do this, however, I'm a bit concerned that since this has not
> > been brought up on the list interested people may not be able to attend
> > on short notice. Also, a time has not been mentioned. I propose
> > 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which
> > will be provided later.
> >
> > If interested people cannot make that time, please speak up so we can
> > arrange an alternate (please don't hesitate to do so, even if you are
> > the only one).
> >
>
> Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org