Re: Recursive core architectural overview
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: Recursive core architectural overview
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
By the way can someone explain what the term Recursive Core Architecture means? Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] To: tuscany-dev@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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
