Hi gang!
In the future of RemoteNeo I envision that there will be a multitude of
transport layer implementations. Today there are two, local and RMI. I know
that I will not be able to implement all the different transport layers that
might get implemented. And even if I did I think it would be a bad idea to
distribute them all with the core RemoteNeo package. If for example there
was a web service transport layer, that would mean that the RemoteNeo jar
would have a dependency on a ton of web framework libraries, and that sounds
very bad to me. So it makes sens to think that the transport layer
implementations will be scattered across different places of the class path.
One thing I have noticed about all implementations that I could think up is
that they can all use an URI to identify the server.
RMI uses an rmi://-uri
Web services uses http(s)://
CORBA uses corbaloc: and corbaname:
the local implementation uses the file:// uri schema
and so on...
Even if it might not be the case that every possible implementation ever
will be able to use an URI for server identification, the fact that all the
once I came up with does is a strong indication that many implementations
will.
This makes me want to be able to use URIs as a way to select which
implementation to use.
<codeExample>
NeoService neo = new RemoteNeo(new
ProtocolSelectingSite("rmi://myhost/Neo")); // use RMI for connection
NeoService neo = new RemoteNeo(new
ProtocolSelectingSite("file:///path/to/store/dir")); // use the local
implementation
NeoService neo = new RemoteNeo(new ProtocolSelectingSite("
http://myhost/Neoservice";)); // use a web service connection
</codeExample>
This has one problem that I would like to get input on. How should we do
registration of implementations?
JDBC solves the same problem by having the implementation classes register
themselves with the core on load time. Then of course the application
programmer has to make sure that any connector (s)he could possibly want to
use is loaded by calling Class.forName(...). In my opinion such code looks
awful. It would be great to get some input on what the rest of you guys
think. What is the most beautiful and simple way to do this? (without
dragging in dependancies on large frameworks such as OSGi.)
So what do you think? Is this a good idea? and if it is, how should we
implement it?
regards,
--
Tobias Ivarsson <[EMAIL PROTECTED]>
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857
_______________________________________________
Neo mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
