Heh, well whatever I'm not saying don't, just it doesn't seem so necessary or interesting to me ATM.
You didn't comment on the bit about the whether a user really needs to know or care about the node URI? ...ant On Tue, Dec 8, 2009 at 11:52 PM, Raymond Feng <[email protected]> wrote: > I don't agree. Using an external XML gives us the flexibility to configure > the node. It is very useful for launchers. In the webapp case, we can start > it from a remote node.xml without packaging the composites/contributions in > the webapp itself. > > Having APIs doesn't conflict with the need to support XML configuration. > It's just different ways to populate the in-memory model. It's somewhat > similar as SCA SCDL vs. the Tuscany models. > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Tuesday, December 08, 2009 3:40 PM > To: <[email protected]> > Subject: Re: [2.x] node configuration attributes > >> On Tue, Dec 8, 2009 at 11:13 PM, Raymond Feng <[email protected]> wrote: >>> >>> See my comments inline. >>> >>> Thanks, >>> Raymond >>> -------------------------------------------------- >>> From: "ant elder" <[email protected]> >>> Sent: Tuesday, December 08, 2009 2:58 PM >>> To: <[email protected]> >>> Subject: Re: [2.x] node configuration attributes >>> >>> [[snip]] >>> >>>> What are the use cases for the XML representation? We dont actually >>>> have anything in 2.x that needs this yet, could it be left till there >>>> is something? >>> >>> Yes, we do. >>> >>> * We use the node.xml files to configure the client and server node in >>> itest-nodes-two-nodes-two-vms-test. >>> * We use it in web application integration so that a node can be created >>> from the webapp from a node.xml which can be local or remote. >> >> Those arent really "use cases" though are they and they both can be >> done fine if not better with the other exsiting APIs. >> >>> * We plan to bring up the Domain Manager which will provision the domain >>> into a set of nodes. The configuration will be served using the node.xml >>> format. >>> >> >> Ok that might be one, but wouldn't it better to work out what any xml >> that might need looks like at the time its being done? >> >>>> >>>>> 4) I don't think node/@uri should be removed. Multiple nodes can have >>>>> the >>>>> same domain URI and domain registry URI. The node URI should uniquely >>>>> identifies a node within an SCA domain. We can use a simple name >>>>> instead >>>>> of >>>>> URI. >>>>> >>>> >>>> What are the use cases for the node URI? The "node" is a concept thats >>>> not in any SCA spec which we're making up for Tuscany so I'm trying to >>>> understand if there are real reasons for needing to expose a node uri >>>> in any user API? >>> >>> Node URI is used to uniquely identify a node within the SCA domain. It's >>> similar as the domain or contribution URI. You can view it as an "id" of >>> the >>> node. If the URI is not provided, we will generate one. Having a >>> user-defined ID makes it simpler to manage the nodes (for example, in the >>> domain manager). >>> >> >> But again, we don't have a domain manager yet so are there any other >> real reasons for a user needing to give a node an id? Users care about >> things like domains and contributions and services, why do they need >> to think about nodes id's? >> >> What i'm trying to get at with these is what do we really need in the >> Java API. Currently theres lots of stuff thats just there for >> historical reasons that I think we can clean up and simplify and I >> hope these reviews will help with that, and we should try to minimize >> adding stuff just in case coz it sounds like it could be useful one >> day. Maybe we will need an XML format too but thats less interesting >> to me at the moment. >> >> ...ant > >
