On 9/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Jean-Sebastien Delfino wrote:
> > Simon Nash wrote:
> >>
> >> Simon Laws wrote:
> >>
> >>> On 9/16/07, ant elder <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> On 9/16/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>> <snip>
> >>>>
> >>>> A question though is should we flip the samples over to use NodeImpl
> >>>> instead
> >>>>
> >>>>> of SCAdomain?
> >>>>
> >>>>
> >>>> To save digging around in the code / ML, what is the new way exactly?
> >>>> Currently things do:
> >>>>
> >>>> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance("
> >>>> helloworldws.composite");
> >>>>
> >>>> what is the new replacement approach?
> >>>>
> >>>> ...ant
> >>>
> >>>
> >>>
> >>>
> >>> org.apache.tuscany.sca.node.impl.NodeImpl node = new SCANodeImpl();
> >>> node.start();
> >>> node.getContributionManager().startContribution(The URL to your
> >>> contribution);
> >>>
> >>> For example, for test purposes the URL could be:
> >>>
> >>> SCANodeUtil.findContributionFromComposite(???.class.getClassLoader(),"
> >>> helloworldws.composite"));
> >>>
> >>> So it's more lines but removes some of the mystery about where the
> >>> contributions are found.
> >>>
> >>> Simon
> >>>
> >> I don't like this at all. Is there a problem with staying with
> >> what we currently have until we can design a clean replacement API?
> >>
> >> Simon
> >>
> >>
> >
> > The non-distributed samples could stay with the current
> > o.a.t.embedded.host.SCADomain.
> >
> > The distributed samples need to move to a cleaner API.
> >
> > I made a proposal for a smaller and cleaner API for use in the
> > distributed samples there:
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-1.0/modules/node-api/src/main/java/org/apache/tuscany/sca/node/smaller/
> >
> >
> > However, I'm not too happy about having two different APIs for
> > non-distributed and distributed...
> >
> > Another option would be to port the distributed samples to the
> > existing o.a.t.embedded.host.SCADomain, hook the existing SCADomain
> > with the distributed Node support, and introduce the Node API only
> > post 1.0.
> >
> > --
> > Jean-Sebastien
> >
>
> More thoughts, trying to cleanup the calculator-distributed API usage
> while minimizing changes and impact on everything else as time to cut
> 1.0 RC2 is approaching :)
>
> We could do the following:
>
> - Keep o.a.t.sca.host.embedded.SCADomain unchanged.
>
> - Copy it into a new o.a.t.sca.domain.SCADomain, in a small domain-api
> module which will only contains that class and only depend on the
> sca-api module. This becomes the API to use to leverage the distributed
> domain support.
>
> - Add one parameter to one of the
> o.a.t.sca.domain.SCADomain.newInstance() methods to take an additional
> nodeURI parameter (as it's needed by nodes to tell the distributed
> domain where they are).
>
> - Move the SCANode interface and its friends to module node and we can
> probably remove the node-api for now.
>
> - Port the calculator-distributed sample to o.a.t.sca.domain.SCADomain.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> sounds ok to me
Assuming this works we then flip o.a.t.s.host.embedded.SCADomain to the
o.a.t.s.domain-api where ever it appears
Simon
