[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ecf-dev] Re: [javagroups-users] JGroups URI for ECF
|
Sorry about the cross-post, but I wanted to notify both the ECF and
JGroups communities about this.
For the moment and just as a starting place, I've implemented a jgroups
URI with the syntax described below. This is changeable as time goes
on, but I wanted to get something in place as quickly as possible...but
would like to settle on a final for this fairly soon.
Note this approach follows the URI standard syntax, and is therefore
parsable by the java.net.URI class.
jgroups://[<ip
address>:<port>]/<channelName>[?stackConfigURL=<url>&stackName=<name>]
So, here are some example URLs:
jgroups:///mychannelname
(channelname=mychannelname, stackconfig=stacks.xml, stackname=udp,
mcastip=same as in stacks.xml/udp, mcastport=same as in stacks.xml/udp)
jgroups:///mychannelname?stackConfigURL=http://www.foo.com/stacks.xml&stackName=tcp
(channelname=mychannelname, stackconfig=http://www.foo.com/stacks.xml,
stackname=tcp, mcastip=same as in foo.com/stacks.xml/udp, mcastport=same
as in foo.com/stacks.xml/udp)
jgroups://228.10.10.11:45589/YourChaNnelname/foobar
(channelname=YourChaNnelname/foobar, stackconfig=stacks.xml,
stackname=udp, mcastip=228.10.10.11:45589, mcastport=45589)
jgroups://228.10.10.11:45589
jgroups:///
(invalid...no channel name)
Some thinking still has to go into the handling of the stackConfigURL
parameter in the query, as for relative file URLs it's not clear what it
should be relative to (e.g. the org.eclipse.ecf.provider.jgroups plugin
can't be modified by clients, so that's a poor choice. The default
directory is probably a poor choice. The classpath is specific to the
plugin, so that won't work. Also it would probably be useful to allow
an extension/extension point to be defined/used to contribute
configurations). In any event, it's still not clear to me so any
suggestions appreciated.
Any comments appreciated.
Scott
Scott Lewis wrote:
Hi Bela,
Bela Ban wrote:
Scott Lewis wrote:
I don't think the multicast address and port should be part of the
URI, as they are defined in the stack config.
True, the *defaults* are specified in the stack config, but it seems to
me extremely likely that the ip address/port/channel name are to be
changed frequently on a per-group basis (so that they don't conflict).
But then you should accommodate other (frequently changing)
parameters too, like the port for TCP stacks... Maybe you can come up
with a generic schme to define these, e.g.
URI?par1=val1&par2=val2 etc where parameters and values would be for
example the mcast_addr
Sure...I could/can/possibly will do this, but since the number of
parameters is so large I'm a little concerned about the total length
of the URI for this approach (I'm not sure if very long URIs are well
supported in existing impls...I will check on that).
RE: accomodating other parameters...at least traditionally, the ip
address (mcast or not) and port (either) have been represented via...e.g.
jgroups://<ip address>:<port>
rather than as
jgroups://path?configFile=<whatever>&port=<whatever>, etc
So that's why I was suggesting the mcast IP and port were 'special'.
But I would like to find a simple/small way to encode all the
information about config...that's why I was thinking about the stack
name/stacks.xml file.
Maybe as an alternative?:
jgroups://228.10.10.10:45588/channelName?stackConfig=udp.xml
Why not
jgroups://channelName?stackConfig=udp.xml&mcast_addr=228.10.10.10&mcast_port=45588
Well, this could be good, but it still seems a little strange to have
the addr and port *not* in the form jgroups://<addr>:<port> since
this is how the URI spec expects other sorts of address (although my
reading is that any given scheme does not have to follow this parsing
convention exactly).
I don't like the fact though that something as central as the config
file is relegated to parameter status...
If you use stacks.xml, then you'd also need to define the <config
name> to be used within stacks.xml.
True. Perhaps if the file is specified in the query segment, and the
stackName is specified via another 'stackName' variable?
jgroups://228.10.10.10:45588/channelName?stackConfig=http://foo.bar.com/stacks/udp.xml&stackName=udp
As you can tell, I still sort of like the following because of the
simplicity:
jgroups:udp://228.10.10.10:45588/channelName
where
jgroups:<stackname>://<mcastip>:<mcastport>/<channelName>&stackConfig=<config
url>
So what about a TCP-based config then ?
I would expect something like:
jgroups:tcp://<tcp address>:<tcp port>/<channelName>
(with stackConfig implicitly assumed to be 'stacks.xml')
Scott
