On Thu, Jan 14, 2010 at 12:46 AM, Raymond Feng <[email protected]> wrote: > More comments: > > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Wednesday, January 13, 2010 9:03 AM > To: <[email protected]> > Subject: Re: SCAClientFactory domainURI format > >> Heh, so thats not what i'd like for either of those, so we need to >> find a way to work this out. >> >> I'd like to avoid _requiring_ some other external config for >> connecting to the domain which is why encoding it in the URI is good. >> It could be fine to have the option of some external config if a user >> really wants to do that, but it doesn't seem particularly user >> friendly or convenient to requiring yet another non-spec defined >> mapping file when it works just fine using the mapped value directly >> in the SCAClientFactory call. > > Adding the physical address to the domainURI doesn't seem to be consistent > with the spec. We probably need a bit clarification from the spec folks. >
The spec doesn't define anything for this, its just a uri so we can use any format for that we like. > We can possibly have to a default scheme for the client and it can be > configured as an attribute in the META-INF/services/... . If the user wants > to customize it, then other ways such as System properties or external files > can be used. > Actually the only reason for having a scheme is because of the memory i had of the spec people saying a design point of the client api was that it should support multiple different factory impls on the client classpath at the same time and which gets used is chosen based on the domain uri. This is not possible with the current OASIS client code, perhaps thats a bug or perhaps the design changed. As it is we could just not use any scheme. >> >> Then with the URI scheme, I'd like to avoid using the explicit >> underlying technology like tribes or hazelcast as thats runtime >> specific and variable so using a generic one seems better and the >> runtime and registry impl can map that to what the particular impl can >> use. >> > > Some of the underlying stacks have their own set of properties to configure. > We can try to generalize them if possible. But I still prefer > to have schemes such as "multicast" or "wka" (well-known-addresses) which > are known protocols. > Neither of those have any sort of standardized or commonly used URI format though, and we need our own uri format as there's multiple parameters. However, are you just suggesting different attribute names in the uri, eg wka=9.120.1.1:1234 instead of remote=9.120.1.1:1234? I'd be fine with changing any of the attribute names. ...ant
