All - I'd like to suggest that where our API requires an identifier for a resource, we provide access for it as a URL, and only where necessary, as a File, String, etc. Allowing a URL will allow the maximum flexibility, since this allows the loading of a resource outside of the classpath. Reducing the number of alternate methods would simplify the API.
When we add a similar method with a String parameter, that could be confusing; does the String represent a string to be passed to Class.getResource(), or a string with which to instantiate a File, or a string with which to instantiate a URL? The reason I'm thinking of this is that I see that I cannot find any reasonably simple way to load a MimeTypes object from a resource outside of the classpath. Someone might want to do this, for example, to point to a resource on a LAN or even on the public Internet. Since the String identifying the resource could easily be converted to a URL, I think we should provide URL capability directly, and possibly remove the String method. In the case of MimeTypes, it requires trivial changes to MimeTypes and MimeTypesReader. What do you think? - Keith -- View this message in context: http://www.nabble.com/URLs-as-Primary-Resource-Identifiers-tf4673177.html#a13350966 Sent from the Apache Tika - Development mailing list archive at Nabble.com.
