Right, so if you look in the DeviceMapClient, there is a convenience method:
loadFromFolder(String folder) This is kind of a remnant from OpenDDR, but basically there is a resource folder that is filled with xml files. Simply point the client to the folder and it will do the rest. Remember, there are at least 4+ xml files which all contribute to the index. Also, there are several internal compilation steps which need to be done inbetween loading these files. Right, the actual names of the files should be configurable, just didnt get to that step yet. The optimal way to do this is to detect the DeviceMap data jar in the classpath and load the resources without asking the user. So what you are asking for is to expose the inner methods of the Loader and have the developer open the device and builder files and the patch files and manually feed them in? They then need to know when to kick off the internal compiling methods too. So this would all have to be exposed. Not sure if an off the shelf developer is going to be able to comprehend the inner guts of this package and properly execute all of this... The simplest approach would be to auto detect the resource jar and use it. Also, create a method for the developer to load files from the local file system. I think its reasonable to make the actual filenames configurable but having the developer drive the file loading and indexing doesn't seem like a good feature. Also, I just moved some classes around into a package hierarchy. ________________________________ From: Radu Cotescu <[email protected]> To: devicemap-dev <[email protected]> Sent: Monday, June 24, 2013 1:57 PM Subject: Re: devicemap java client cleanup Hi Reza, > 1 and 2) There is a generic Loader (org.apache.devicemap.client.Loader) > which takes in Readers (like an inputstream but it has an encoding: UTF8). > FileLoader then wraps this and loads files and I was planning on creating a > JarLoader which will detect and load resources from a jar. So it should > probably be organized a bit better (interface and package), but I think if > there is a new loading method, just wrap Loader, no? Why should we provide multiple loaders and try to imagine all the use cases when we could have only one way to initialise the client? The final users of our client are developers. I'm sure they can wrap whatever type of data source into an InputStream - files from the file system, files from a JAR, JCR nodes, Apache Sling resources, URLs, etc. I'm in favour of keeping things as simple as possible. WDYT? Cheers, Radu
