You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Nash <na...@hursley.ibm.com> on 2007/07/12 17:45:04 UTC
DAS packaging (was Re: SCA 0.92 release?)
Thanks for restarting the discussion on this. I think DAS is in
a special position because it's part of our project and therefore
we have the opportunity to choose whether these DAS components are
packaged and released with Tuscany SCA or with Tuscany DAS.
For other SCA extensions, we as Tuscany could only choose whether
to make them "core" or "additional" since it would be up to the other
project to decide whether to package them as part of its releases.
I'd therefore like to take these as separate discussions (hence
the change of subject line on this post).
On the DAS packaging specifically, I'm unable to build the SCA trunk
because of implementation.das issues (see my post of yesterday).
I'm sure we'll figure these issues out eventually, but this points
out the problems with tightly coupling SCA builds to a particular
level of DAS, which is moving forward rapidly (that's great!)
I think the alternative packaging that I proposed would be better
for both SCA and for DAS. For SCA, it reduces the number of
moving parts, instability, and opportunity for build breaks.
For DAS, it creates an component that extends both SCA and SDO
to add significant value. These base dependencies should be quite
stable from now on, so DAS builds would be largely independent of
the current state of the SCA and SDO trunks.
What do other people think about this?
Simon
ant elder wrote:
> Was there any further discussion about this (I'm catching up on mail after
> being away so likely missed things)? Its an interesting question i
> think. So
> far we seem to be operating in that everyone can just add what extensions
> they choose to trunk we don't need to get any consensus first. I quite like
> this approach but there are other ways. One alternative could be to have
> some 'core' set of extensions and another 'additional' set. The core set we
> deem by consensus are the official/production/stable/??? ones, and we need
> to vote to get an extension included in that core set, but anyone can add
> what they like to the 'additional' set. Do others have any opinions on this
> or suggestions on alternative approaches?
>
> ...ant
>
> On 7/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>>
>> I'd like to restart the earlier discussion in
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19224.html
>> about whether implementation.das and implementation.data should be
>> packaged with SCA releases or DAS releases.
>>
>> I think it's better for these to be packaged with DAS releases as
>> the code will be more aligned with evolving DAS capabilities than
>> with evolving SCA capabilities. This will allow new features to be
>> added as and when it makes sense for DAS to move up to support them.
>>
>> Simon
>>
>> Luciano Resende wrote:
>>
>> > Now that we are going to have a DAS release out, I'd like to plan to
>> > have implementation.das and implementation.data available for the next
>> > release.
>> >
>> > I also like to have some improvements to the Contribution Services,
>> > such as import/export and other scenarios that have been described on
>> > the list recently. I'll update the wiki with these items.
>> >
>> > On 7/2/07, haleh mahbod <hm...@gmail.com> wrote:
>> >
>> >> Posting to tuscany-user list as well to get input.
>> >>
>> >> Any real world scenarios/samples that can be shared by users? It would
>> be
>> >> great if we could start building a library of tips and real usage
>> >> examples.. a knowledge base.
>> >>
>> >> Thanks
>> >> Haleh
>> >>
>> >> On 7/2/07, Simon Laws <si...@googlemail.com> wrote:
>> >> >
>> >> > On 7/2/07, ant elder <an...@apache.org> wrote:
>> >> > >
>> >> > > On 7/2/07, Simon Laws <si...@googlemail.com> wrote:
>> >> > > >
>> >> > > > On 7/2/07, Venkata Krishnan <fo...@gmail.com> wrote:
>> >> > > > >
>> >> > > > > Hi,
>> >> > > > >
>> >> > > > > I am looking at the Policy Framework and shall update the wiki
>> on
>> >> > the
>> >> > > > > specifics soon. Once this is done to some level, I'd also
>> >> like to
>> >> > > help
>> >> > > > a
>> >> > > > > bit with the ws-* things (may be WS-Security to start with)
>> >> that Ant
>> >> > > has
>> >> > > > > listed on the wiki page.
>> >> > > > >
>> >> > > > > - Venkat
>> >> > > > >
>> >> > > > > On 6/30/07, ant elder <an...@gmail.com> wrote:
>> >> > > > > >
>> >> > > > > > With the SCA 0.91 release now being voted on how about
>> >> starting on
>> >> > > > 0.92?
>> >> > > > > >
>> >> > > > > > I've already been adding some things I'm interested in
>> getting
>> >> > done
>> >> > > to
>> >> > > > > the
>> >> > > > > > next release wiki page -
>> >> > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
>>
>> >>
>> >> > > > > > so far thats mainly related to improving web services
>> >> > functionality.
>> >> > > > > >
>> >> > > > > > So anyone else interested in helping with an 0.92 release or
>> >> have
>> >> > > any
>> >> > > > > > function they'd like to suggest or add to the wiki page? How
>> >> does
>> >> > > > aiming
>> >> > > > > > for
>> >> > > > > > getting it done 4 - 6 weeks again sound?
>> >> > > > > >
>> >> > > > > > ...ant
>> >> > > > > >
>> >> > > >
>> >> > > >
>> >> > > > The above link has an extrenuous "-" on the end. Taking that off
>> >> gets
>> >> > me
>> >> > > > to
>> >> > > > the page. Can we move this information across the to the new
>> wiki
>> >> > space
>> >> > > (
>> >> > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so
>> >> that
>> >> > > > everyone (including non committers) can add to it?
>> >> > > >
>> >> > > > I'm working on the next phase of the distributed runtime which I
>> >> want
>> >> > to
>> >> > > > get
>> >> > > > into the next release. This involves a few items.
>> >> > > >
>> >> > > > SCA Binding
>> >> > > > Topology model
>> >> > > > Distributed domain
>> >> > > > Node implementation
>> >> > > > Management assembly
>> >> > > >
>> >> > > > Also I need some of the ws items, in particular the ability to
>> run
>> >> > > without
>> >> > > > wsdl, so can help out there.
>> >> > > >
>> >> > > > We need to do something about logging and events to improvide
>> >> runtime
>> >> > > > usability. We've talked about it before but not done anything
>> yet.
>> >> > Ties
>> >> > > > into
>> >> > > > the management assembly.
>> >> > > >
>> >> > > > I'd also like to see the JMS binding in the release but can't
>> >> commit
>> >> > to
>> >> > > > doing lots more work on including spec features. It's been
>> working
>> >> > fine
>> >> > > > for
>> >> > > > me in my limited synchronous/rpc model. If I get time I'll take
>> >> a look
>> >> > > to
>> >> > > > see what it will take to add minimum asynch support but if
>> >> anyone else
>> >> > > > fancies having a go at this then it's a good way to learn about
>> >> > Tuscany
>> >> > > > extensions.
>> >> > >
>> >> > >
>> >> > > All these sound good, but its starting to sound a lot to get done
>> in
>> >> > just
>> >> > > a
>> >> > > few weeks. How does the suggesting timeframe of 4 or so weeks
>> sound?
>> >> > >
>> >> > > We'd talked once about having a release specifically targeting
>> things
>> >> > like
>> >> > > logging, events, and error handling. I'd still like to do that, if
>> >> > anyone
>> >> > > wants to start now thats great but I doubt I'd have much time to
>> help
>> >> > this
>> >> > > release.
>> >> > >
>> >> > > ...ant
>> >> > >
>> >> > I think 4 weeks is a bit too short. Given that we are getting into
>> >> holday
>> >> > season I like the sound of 6 weeks better.
>> >> >
>> >> > I agree there is a lot there but in the spirit of your WS list I
>> wasn't
>> >> > proposing that all of it gets done. I do think we need to make a
>> >> start on
>> >> > the logging/errors sooner rather than later though even if it
>> >> doesn't get
>> >> > into the next release. I'll offer my effort to help move it along
>> >> once the
>> >> > distributed work starts drawing to a close.
>> >> >
>> >> > Simon
>> >> >
>> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS packaging (was Re: SCA 0.92 release?)
Posted by Simon Nash <na...@hursley.ibm.com>.
I agree that data integration is needed in SCA and that DAS has an
important role to play in this. This close connection is the
reason why DAS (and SDO) are part of the Tuscany project. And
beacuse of this, we as the Tuscany project have the opportunity to
decide the optimal packaging of the various interdependent pieces.
The creates a different situation than the one we have with the
other SCA extension dependencies that involve other projects.
I think the main reason to have implementation-das packaged with
DAS is that the functionality and evolution of implementation-das
is likely to be more closely bound to DAS evolution than to
SCA evolution. DAS isn't yet a published spec, and the declarative
DAS for data service exposure is a new concept that I would expect
to evolve quite rapidly. The reference [1] below alludes to this.
It's much less likely that SCA would undergo changes that would
require changes to DAS or implementation-das (or vice versa).
Simon
Luciano Resende wrote:
> Data integration is something needed in SCA. The main idea around
> Implementation.das [1] is to integrate DAS and SCA to allow exposing
> services that interact with a persistent layer in a declarative
> fashion hiding some of the implementation details from the service
> developer. Some more info is also available in [3].
>
> As discussed on the following thread [4], we have many other
> dependencies, and I'd like to still treat the DAS dependency as the
> others. As for inclusion on the next release distros, I think this is
> something that needs to be accessed around the time we cut the next
> branch, if you would ask me today, I'd say implementation.das still
> need a little more work before it could be included on a release, and
> it is also waiting for the DAS beta1 release to get approved.
>
> As for your comment around build issue :
>
>> On the DAS packaging specifically, I'm unable to build the SCA trunk
>> because of implementation.das issues (see my post of yesterday).
>> I'm sure we'll figure these issues out eventually, but this points
>> out the problems with tightly coupling SCA builds to a particular
>> level of DAS, which is moving forward rapidly (that's great!)
>
>
> this was caused by SDO dependencies, and affected many other modules
> on the Tuscany SCA build, but looks like Raymond and I have addressed
> all of them now and things should be back to normal and stable. Note
> that you might need to re-build the latest SDO from trunk to get the
> fixes.
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18908.html
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09978.html
> [3]
> http://incubator.apache.org/tuscany/das-overview.data/das-data-services-v01.pdf
>
> [4] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19072.html
>
>
> On 7/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>> Thanks for restarting the discussion on this. I think DAS is in
>> a special position because it's part of our project and therefore
>> we have the opportunity to choose whether these DAS components are
>> packaged and released with Tuscany SCA or with Tuscany DAS.
>> For other SCA extensions, we as Tuscany could only choose whether
>> to make them "core" or "additional" since it would be up to the other
>> project to decide whether to package them as part of its releases.
>>
>> I'd therefore like to take these as separate discussions (hence
>> the change of subject line on this post).
>>
>> On the DAS packaging specifically, I'm unable to build the SCA trunk
>> because of implementation.das issues (see my post of yesterday).
>> I'm sure we'll figure these issues out eventually, but this points
>> out the problems with tightly coupling SCA builds to a particular
>> level of DAS, which is moving forward rapidly (that's great!)
>>
>> I think the alternative packaging that I proposed would be better
>> for both SCA and for DAS. For SCA, it reduces the number of
>> moving parts, instability, and opportunity for build breaks.
>> For DAS, it creates an component that extends both SCA and SDO
>> to add significant value. These base dependencies should be quite
>> stable from now on, so DAS builds would be largely independent of
>> the current state of the SCA and SDO trunks.
>>
>> What do other people think about this?
>>
>> Simon
>>
>> ant elder wrote:
>>
>> > Was there any further discussion about this (I'm catching up on mail
>> after
>> > being away so likely missed things)? Its an interesting question i
>> > think. So
>> > far we seem to be operating in that everyone can just add what
>> extensions
>> > they choose to trunk we don't need to get any consensus first. I
>> quite like
>> > this approach but there are other ways. One alternative could be to
>> have
>> > some 'core' set of extensions and another 'additional' set. The core
>> set we
>> > deem by consensus are the official/production/stable/??? ones, and
>> we need
>> > to vote to get an extension included in that core set, but anyone
>> can add
>> > what they like to the 'additional' set. Do others have any opinions
>> on this
>> > or suggestions on alternative approaches?
>> >
>> > ...ant
>> >
>> > On 7/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
>> >
>> >>
>> >> I'd like to restart the earlier discussion in
>> >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19224.html
>> >> about whether implementation.das and implementation.data should be
>> >> packaged with SCA releases or DAS releases.
>> >>
>> >> I think it's better for these to be packaged with DAS releases as
>> >> the code will be more aligned with evolving DAS capabilities than
>> >> with evolving SCA capabilities. This will allow new features to be
>> >> added as and when it makes sense for DAS to move up to support them.
>> >>
>> >> Simon
>> >>
>> >> Luciano Resende wrote:
>> >>
>> >> > Now that we are going to have a DAS release out, I'd like to plan to
>> >> > have implementation.das and implementation.data available for the
>> next
>> >> > release.
>> >> >
>> >> > I also like to have some improvements to the Contribution Services,
>> >> > such as import/export and other scenarios that have been
>> described on
>> >> > the list recently. I'll update the wiki with these items.
>> >> >
>> >> > On 7/2/07, haleh mahbod <hm...@gmail.com> wrote:
>> >> >
>> >> >> Posting to tuscany-user list as well to get input.
>> >> >>
>> >> >> Any real world scenarios/samples that can be shared by users? It
>> would
>> >> be
>> >> >> great if we could start building a library of tips and real usage
>> >> >> examples.. a knowledge base.
>> >> >>
>> >> >> Thanks
>> >> >> Haleh
>> >> >>
>> >> >> On 7/2/07, Simon Laws <si...@googlemail.com> wrote:
>> >> >> >
>> >> >> > On 7/2/07, ant elder <an...@apache.org> wrote:
>> >> >> > >
>> >> >> > > On 7/2/07, Simon Laws <si...@googlemail.com> wrote:
>> >> >> > > >
>> >> >> > > > On 7/2/07, Venkata Krishnan <fo...@gmail.com> wrote:
>> >> >> > > > >
>> >> >> > > > > Hi,
>> >> >> > > > >
>> >> >> > > > > I am looking at the Policy Framework and shall update
>> the wiki
>> >> on
>> >> >> > the
>> >> >> > > > > specifics soon. Once this is done to some level, I'd also
>> >> >> like to
>> >> >> > > help
>> >> >> > > > a
>> >> >> > > > > bit with the ws-* things (may be WS-Security to start with)
>> >> >> that Ant
>> >> >> > > has
>> >> >> > > > > listed on the wiki page.
>> >> >> > > > >
>> >> >> > > > > - Venkat
>> >> >> > > > >
>> >> >> > > > > On 6/30/07, ant elder <an...@gmail.com> wrote:
>> >> >> > > > > >
>> >> >> > > > > > With the SCA 0.91 release now being voted on how about
>> >> >> starting on
>> >> >> > > > 0.92?
>> >> >> > > > > >
>> >> >> > > > > > I've already been adding some things I'm interested in
>> >> getting
>> >> >> > done
>> >> >> > > to
>> >> >> > > > > the
>> >> >> > > > > > next release wiki page -
>> >> >> > > > > >
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
>>
>> >>
>> >> >>
>> >> >> > > > > > so far thats mainly related to improving web services
>> >> >> > functionality.
>> >> >> > > > > >
>> >> >> > > > > > So anyone else interested in helping with an 0.92
>> release or
>> >> >> have
>> >> >> > > any
>> >> >> > > > > > function they'd like to suggest or add to the wiki
>> page? How
>> >> >> does
>> >> >> > > > aiming
>> >> >> > > > > > for
>> >> >> > > > > > getting it done 4 - 6 weeks again sound?
>> >> >> > > > > >
>> >> >> > > > > > ...ant
>> >> >> > > > > >
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > The above link has an extrenuous "-" on the end. Taking
>> that off
>> >> >> gets
>> >> >> > me
>> >> >> > > > to
>> >> >> > > > the page. Can we move this information across the to the new
>> >> wiki
>> >> >> > space
>> >> >> > > (
>> >> >> > > >
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so
>> >> >> that
>> >> >> > > > everyone (including non committers) can add to it?
>> >> >> > > >
>> >> >> > > > I'm working on the next phase of the distributed runtime
>> which I
>> >> >> want
>> >> >> > to
>> >> >> > > > get
>> >> >> > > > into the next release. This involves a few items.
>> >> >> > > >
>> >> >> > > > SCA Binding
>> >> >> > > > Topology model
>> >> >> > > > Distributed domain
>> >> >> > > > Node implementation
>> >> >> > > > Management assembly
>> >> >> > > >
>> >> >> > > > Also I need some of the ws items, in particular the
>> ability to
>> >> run
>> >> >> > > without
>> >> >> > > > wsdl, so can help out there.
>> >> >> > > >
>> >> >> > > > We need to do something about logging and events to improvide
>> >> >> runtime
>> >> >> > > > usability. We've talked about it before but not done anything
>> >> yet.
>> >> >> > Ties
>> >> >> > > > into
>> >> >> > > > the management assembly.
>> >> >> > > >
>> >> >> > > > I'd also like to see the JMS binding in the release but can't
>> >> >> commit
>> >> >> > to
>> >> >> > > > doing lots more work on including spec features. It's been
>> >> working
>> >> >> > fine
>> >> >> > > > for
>> >> >> > > > me in my limited synchronous/rpc model. If I get time I'll
>> take
>> >> >> a look
>> >> >> > > to
>> >> >> > > > see what it will take to add minimum asynch support but if
>> >> >> anyone else
>> >> >> > > > fancies having a go at this then it's a good way to learn
>> about
>> >> >> > Tuscany
>> >> >> > > > extensions.
>> >> >> > >
>> >> >> > >
>> >> >> > > All these sound good, but its starting to sound a lot to get
>> done
>> >> in
>> >> >> > just
>> >> >> > > a
>> >> >> > > few weeks. How does the suggesting timeframe of 4 or so weeks
>> >> sound?
>> >> >> > >
>> >> >> > > We'd talked once about having a release specifically targeting
>> >> things
>> >> >> > like
>> >> >> > > logging, events, and error handling. I'd still like to do
>> that, if
>> >> >> > anyone
>> >> >> > > wants to start now thats great but I doubt I'd have much
>> time to
>> >> help
>> >> >> > this
>> >> >> > > release.
>> >> >> > >
>> >> >> > > ...ant
>> >> >> > >
>> >> >> > I think 4 weeks is a bit too short. Given that we are getting
>> into
>> >> >> holday
>> >> >> > season I like the sound of 6 weeks better.
>> >> >> >
>> >> >> > I agree there is a lot there but in the spirit of your WS list I
>> >> wasn't
>> >> >> > proposing that all of it gets done. I do think we need to make a
>> >> >> start on
>> >> >> > the logging/errors sooner rather than later though even if it
>> >> >> doesn't get
>> >> >> > into the next release. I'll offer my effort to help move it along
>> >> >> once the
>> >> >> > distributed work starts drawing to a close.
>> >> >> >
>> >> >> > Simon
>> >> >> >
>> >> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS packaging (was Re: SCA 0.92 release?)
Posted by Luciano Resende <lu...@gmail.com>.
Data integration is something needed in SCA. The main idea around
Implementation.das [1] is to integrate DAS and SCA to allow exposing
services that interact with a persistent layer in a declarative
fashion hiding some of the implementation details from the service
developer. Some more info is also available in [3].
As discussed on the following thread [4], we have many other
dependencies, and I'd like to still treat the DAS dependency as the
others. As for inclusion on the next release distros, I think this is
something that needs to be accessed around the time we cut the next
branch, if you would ask me today, I'd say implementation.das still
need a little more work before it could be included on a release, and
it is also waiting for the DAS beta1 release to get approved.
As for your comment around build issue :
> On the DAS packaging specifically, I'm unable to build the SCA trunk
> because of implementation.das issues (see my post of yesterday).
> I'm sure we'll figure these issues out eventually, but this points
> out the problems with tightly coupling SCA builds to a particular
> level of DAS, which is moving forward rapidly (that's great!)
this was caused by SDO dependencies, and affected many other modules
on the Tuscany SCA build, but looks like Raymond and I have addressed
all of them now and things should be back to normal and stable. Note
that you might need to re-build the latest SDO from trunk to get the
fixes.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18908.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09978.html
[3] http://incubator.apache.org/tuscany/das-overview.data/das-data-services-v01.pdf
[4] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19072.html
On 7/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
> Thanks for restarting the discussion on this. I think DAS is in
> a special position because it's part of our project and therefore
> we have the opportunity to choose whether these DAS components are
> packaged and released with Tuscany SCA or with Tuscany DAS.
> For other SCA extensions, we as Tuscany could only choose whether
> to make them "core" or "additional" since it would be up to the other
> project to decide whether to package them as part of its releases.
>
> I'd therefore like to take these as separate discussions (hence
> the change of subject line on this post).
>
> On the DAS packaging specifically, I'm unable to build the SCA trunk
> because of implementation.das issues (see my post of yesterday).
> I'm sure we'll figure these issues out eventually, but this points
> out the problems with tightly coupling SCA builds to a particular
> level of DAS, which is moving forward rapidly (that's great!)
>
> I think the alternative packaging that I proposed would be better
> for both SCA and for DAS. For SCA, it reduces the number of
> moving parts, instability, and opportunity for build breaks.
> For DAS, it creates an component that extends both SCA and SDO
> to add significant value. These base dependencies should be quite
> stable from now on, so DAS builds would be largely independent of
> the current state of the SCA and SDO trunks.
>
> What do other people think about this?
>
> Simon
>
> ant elder wrote:
>
> > Was there any further discussion about this (I'm catching up on mail after
> > being away so likely missed things)? Its an interesting question i
> > think. So
> > far we seem to be operating in that everyone can just add what extensions
> > they choose to trunk we don't need to get any consensus first. I quite like
> > this approach but there are other ways. One alternative could be to have
> > some 'core' set of extensions and another 'additional' set. The core set we
> > deem by consensus are the official/production/stable/??? ones, and we need
> > to vote to get an extension included in that core set, but anyone can add
> > what they like to the 'additional' set. Do others have any opinions on this
> > or suggestions on alternative approaches?
> >
> > ...ant
> >
> > On 7/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> >>
> >> I'd like to restart the earlier discussion in
> >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19224.html
> >> about whether implementation.das and implementation.data should be
> >> packaged with SCA releases or DAS releases.
> >>
> >> I think it's better for these to be packaged with DAS releases as
> >> the code will be more aligned with evolving DAS capabilities than
> >> with evolving SCA capabilities. This will allow new features to be
> >> added as and when it makes sense for DAS to move up to support them.
> >>
> >> Simon
> >>
> >> Luciano Resende wrote:
> >>
> >> > Now that we are going to have a DAS release out, I'd like to plan to
> >> > have implementation.das and implementation.data available for the next
> >> > release.
> >> >
> >> > I also like to have some improvements to the Contribution Services,
> >> > such as import/export and other scenarios that have been described on
> >> > the list recently. I'll update the wiki with these items.
> >> >
> >> > On 7/2/07, haleh mahbod <hm...@gmail.com> wrote:
> >> >
> >> >> Posting to tuscany-user list as well to get input.
> >> >>
> >> >> Any real world scenarios/samples that can be shared by users? It would
> >> be
> >> >> great if we could start building a library of tips and real usage
> >> >> examples.. a knowledge base.
> >> >>
> >> >> Thanks
> >> >> Haleh
> >> >>
> >> >> On 7/2/07, Simon Laws <si...@googlemail.com> wrote:
> >> >> >
> >> >> > On 7/2/07, ant elder <an...@apache.org> wrote:
> >> >> > >
> >> >> > > On 7/2/07, Simon Laws <si...@googlemail.com> wrote:
> >> >> > > >
> >> >> > > > On 7/2/07, Venkata Krishnan <fo...@gmail.com> wrote:
> >> >> > > > >
> >> >> > > > > Hi,
> >> >> > > > >
> >> >> > > > > I am looking at the Policy Framework and shall update the wiki
> >> on
> >> >> > the
> >> >> > > > > specifics soon. Once this is done to some level, I'd also
> >> >> like to
> >> >> > > help
> >> >> > > > a
> >> >> > > > > bit with the ws-* things (may be WS-Security to start with)
> >> >> that Ant
> >> >> > > has
> >> >> > > > > listed on the wiki page.
> >> >> > > > >
> >> >> > > > > - Venkat
> >> >> > > > >
> >> >> > > > > On 6/30/07, ant elder <an...@gmail.com> wrote:
> >> >> > > > > >
> >> >> > > > > > With the SCA 0.91 release now being voted on how about
> >> >> starting on
> >> >> > > > 0.92?
> >> >> > > > > >
> >> >> > > > > > I've already been adding some things I'm interested in
> >> getting
> >> >> > done
> >> >> > > to
> >> >> > > > > the
> >> >> > > > > > next release wiki page -
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
> >>
> >> >>
> >> >> > > > > > so far thats mainly related to improving web services
> >> >> > functionality.
> >> >> > > > > >
> >> >> > > > > > So anyone else interested in helping with an 0.92 release or
> >> >> have
> >> >> > > any
> >> >> > > > > > function they'd like to suggest or add to the wiki page? How
> >> >> does
> >> >> > > > aiming
> >> >> > > > > > for
> >> >> > > > > > getting it done 4 - 6 weeks again sound?
> >> >> > > > > >
> >> >> > > > > > ...ant
> >> >> > > > > >
> >> >> > > >
> >> >> > > >
> >> >> > > > The above link has an extrenuous "-" on the end. Taking that off
> >> >> gets
> >> >> > me
> >> >> > > > to
> >> >> > > > the page. Can we move this information across the to the new
> >> wiki
> >> >> > space
> >> >> > > (
> >> >> > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so
> >> >> that
> >> >> > > > everyone (including non committers) can add to it?
> >> >> > > >
> >> >> > > > I'm working on the next phase of the distributed runtime which I
> >> >> want
> >> >> > to
> >> >> > > > get
> >> >> > > > into the next release. This involves a few items.
> >> >> > > >
> >> >> > > > SCA Binding
> >> >> > > > Topology model
> >> >> > > > Distributed domain
> >> >> > > > Node implementation
> >> >> > > > Management assembly
> >> >> > > >
> >> >> > > > Also I need some of the ws items, in particular the ability to
> >> run
> >> >> > > without
> >> >> > > > wsdl, so can help out there.
> >> >> > > >
> >> >> > > > We need to do something about logging and events to improvide
> >> >> runtime
> >> >> > > > usability. We've talked about it before but not done anything
> >> yet.
> >> >> > Ties
> >> >> > > > into
> >> >> > > > the management assembly.
> >> >> > > >
> >> >> > > > I'd also like to see the JMS binding in the release but can't
> >> >> commit
> >> >> > to
> >> >> > > > doing lots more work on including spec features. It's been
> >> working
> >> >> > fine
> >> >> > > > for
> >> >> > > > me in my limited synchronous/rpc model. If I get time I'll take
> >> >> a look
> >> >> > > to
> >> >> > > > see what it will take to add minimum asynch support but if
> >> >> anyone else
> >> >> > > > fancies having a go at this then it's a good way to learn about
> >> >> > Tuscany
> >> >> > > > extensions.
> >> >> > >
> >> >> > >
> >> >> > > All these sound good, but its starting to sound a lot to get done
> >> in
> >> >> > just
> >> >> > > a
> >> >> > > few weeks. How does the suggesting timeframe of 4 or so weeks
> >> sound?
> >> >> > >
> >> >> > > We'd talked once about having a release specifically targeting
> >> things
> >> >> > like
> >> >> > > logging, events, and error handling. I'd still like to do that, if
> >> >> > anyone
> >> >> > > wants to start now thats great but I doubt I'd have much time to
> >> help
> >> >> > this
> >> >> > > release.
> >> >> > >
> >> >> > > ...ant
> >> >> > >
> >> >> > I think 4 weeks is a bit too short. Given that we are getting into
> >> >> holday
> >> >> > season I like the sound of 6 weeks better.
> >> >> >
> >> >> > I agree there is a lot there but in the spirit of your WS list I
> >> wasn't
> >> >> > proposing that all of it gets done. I do think we need to make a
> >> >> start on
> >> >> > the logging/errors sooner rather than later though even if it
> >> >> doesn't get
> >> >> > into the next release. I'll offer my effort to help move it along
> >> >> once the
> >> >> > distributed work starts drawing to a close.
> >> >> >
> >> >> > Simon
> >> >> >
> >> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org