Mmh,
personally I think OSGi is a good match between value and small
footprint, but otherwise, you maybe could utilize the Java protocol
handler mechanism. Not that dynamic (IIRC you cannot change protocol
registrations runtime, only boot time) but still quite powerful:
http://java.sun.com/developer/onlineTraining/protocolhandlers/
/peter
On Fri, Jun 27, 2008 at 1:47 PM, Tobias Ivarsson
<[EMAIL PROTECTED]> wrote:
> 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
>
>
--
GTalk: neubauer.peter
Skype peter.neubauer
ICQ 18762544
GTalk neubauer.peter
Phone +46704 106975
LinkedIn http://www.linkedin.com/in/neubauer
http://www.neo4j.org - New Energy for Data - the Graph Database.
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
_______________________________________________
Neo mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
