On Feb 23, 2005, at 9:08 PM, Miguel wrote:
Hi as far as I can see currently jmol supports only predefined list of the protocols:
form FileManager source:
final String[] urlPrefixes = {"http:", "https:", "ftp:", "file:"};
and it's used in the classifyName method
for (int i = 0; i < urlPrefixes.length; ++i) { ..... }
so if we want to use our custom protocol
custom protocol : internet/open source :: oil : water
I am puzzled ... I don't know what your application is, but help me understand what are the benefits of using a custom protocol.
there is no benefit it's essential requirement for our application
our application uses its own class loaders and should be able to extract data from many possible URI
(via JNDI sources, from jar files, from some special organized set of items)
we set url handlers for our protocols
one of them for example we call ped:// that will retrieve data from specially organized file we call activity
format of that file currently is zip, but it could be any arbitrary format
so bottom line we supply to java runtime our own url handler
so java will know how to handle url like ped://foo.pdb
there is no way as to handle it by ourself and use loading model from the string that's wasting memory I think (especially if models are huge)
Maybe. But it probably won't make any measurable difference. You are
already network bandwidth limited and file parsing is already incredibly
inefficient.
if model is about few megabytes also ped protocol I mentioned above isn't network protocol so we don't have to deal with network at all
This seems to me to be a bigger problem than simply allowing additional string prefixes.
Q: Can the Java class library deal with this custom protocol?
Q: Where is the driver code?
yes it can
there is standard protocol to registering custom URL handlers
you can take a look at java.net.URLStreamHandler class
and associates
also take a look at the method setURLStreamHandlerFactory of the java.net.URL class
and to the source of the URL.java
static URLStreamHandler getURLStreamHandler(String protocol) ....
you'll see as Java handles different protocols
here is a procedure:
we create URLStreamHandlerFactory that will provide JVM with URLHandler for custom protocol
and we have to register that factory at least once per JVM via setURLStreamHandlerFactory method:
so java will ask that factory for every requested protocol via URLStreamHandlerFactory's method
createURLStreamHandler
so factory will supply JVM with appropriate URLStreamHandler
(you can do that without factory but you have to follow to packaging rules for such a handlers)
so that custom URLStreamHandler will parse URL, open connection (and will supply custom URLConnection instance)
custom URLConnection instance will provide necessary input/output stream to the consumer
so if jmol will ask for loading model from the ped://foo.pdb
URL will ask registered factory to get appropriate handler
so we will supply JVM with appropriate handler
and that handler will provide all necessary resources to the URL "client"
if you don't supply factory the standard way java will discover protocols is the following:
lets say we have protocol ped:
so we have to create class sun.net.www.protocol.ped.Handler
and java will instantiate that class via reflection mechanism
for example we have special handler to load resources from the jars
(now it's obsolete because we can use jar: protocol via standard java's facility)
sun.net.www.protocol.ccjar.Handler
and that handler provides special URLConnection class org.concord.client.CCJarURLConnection
that will handle all resources retrieving operation
but for any client that will require URL like ccjar://.....
won't be any difference from regular http:// or file:// protocols
hope my explanations were good
Miguel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
Dmitry Markman
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
