I snipped out the sections where we seemed to agree to make that email
smaller.
[snip]
Simon Laws wrote:
I think we need to distinguish:
- creating a domain... createDomain(domainURI)
- getting a handle to an existing domain... getDomain(domainURI)
I think we need to distiguish between these two but I would rather it were
done through factory implementation rather than interface operation. I think
having two operation causes potential confusion to the user about which to
call. They potentially need to know how the domain has been implemented to
make this decision.
I think we have two different use cases:
- Tuscany runtime code uses an SPI to create a domain.
- Application code uses an API to get an handle to a domain.
So +1 for two different factories and interfaces for (1) the SPI and (2)
the API, instead of one interface with 2 methods.
Makes sense?
[snip]
I've also found the contributionLocation and composites parameters of
the
newInstance methods confusing as well.
It's not the first time we bump into this. Having a method take a
contribution location makes a lot of sense. The problem is figuring that
location...
a) in Eclipse or another IDE
b) with a JAR produced by Maven
c) with classes under test/classes
Do you mean that the problem is figuring out what the location is as we
move between these environments. The code that we have in svn currently
doesn't take account of these environments explicitly but follows an
algorithms of either accepting the absolute location you provide or looking
on the classpath for various files (.composite, sca-contribution.xml etc.)
to determine where the contribution is.
Right, but people are saying that it's confusing, so I'm only saying:
1) OK let's acknowledge that it's confusing
2) Let's come up with a better option
3) If people want to specify the contribution URL instead of deriving it
automatically, how can that URL be portable between different environments?
With the API you're proposing you're going to have to write the following:
URL contributionLocation = <magic code>;
Whatever whateverFactory = createWhatever(contributionLocation);
Any good idea on how to write the <magic code> that works with [a], [b]
and [c]?
I don't think we have magic code at present.
[a] we rely on the classpath
I am assuming that we're going to remove the algorithm that relies on
the presence of a composite file on the classpath to find the
contribution, since people are finding it confusing :)
So we need to come up with a recommendation on how to write:
URL contributionLocation = ???
I have no idea what ??? should look like. That's what I meant by "magic
code", maybe I should have said "magic URL that just works the same way
in cases a/b/c".
Let's look at concrete code:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/samples/SampleDomainWithClient.java
this line:
domain.addContribution(new
URL("file://home/bob/tuscany/sample-calculator-ws-1.0.jar"));
is a problem, as it won't work in an IDE when you don't have the JAR yet.
What do people think we should pass in new URL("???")?
[snip]
+1 to separate the two:
- Domain - you go to a domain to declare contributions and domain
composites
- Node - you go to a node to run components (to simplify let's say that
a node runs a composite containing components)
Why not a contribution containing a composite containing components? The
composite will need to artifacts of its containing contribution anyhow
You give to a node a set of contributions and the name of a composite
declaring the components to run. Is that what you meant? or are you
thinking about something different?
[snip]
- A node does not have complicated lifecycle operations, a node is
created, configured with a composite and the contributions needed by the
composite, runs off of that, then dies or gets recycled. In other words
a node is immutable.
+0.5 Immutable once it's started?
Yes, immutable once it's started.
[snip]
We will need management interfaces, but I think we should know where
we're going with the basic concepts and experiment with simpler APIs -
just two interfaces Domain and Node - before adding more APIs.
By management I mean
Add/remove contribution
Add/remove composite
Start/stop component
Am completely happy to leave
getNodeInfo
getComponentInfo
etc.
Until later.
I would even leave start/stop component and the componentInfo / nodeInfo
out of the API for now, and only have start/stop composite, as if people
want to manage individual components they can put them in different
composites.
I'm not saying that we should not start/stop component at some point,
only saying let's stick to the strict minimum now, let this mature a
bit, add more capabilities when we have built and played with some
scenarios for a while. New ideas will pop up then, probably different
from everything we're discussing today :)
[snip]
I skipped your comments on the interfaces for now and am going to report
them in the actual code as FIXME/TODOs to help review them. Will post
again when it's done.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
