>> Let's not limit ourselves to thinking only in file system abstractions
Im not. How else can we load data apart from File, Jar, or URL?
So heres my counter point, lets make sure its easy to use. I think most
developers want drop ins with zero configuration. Take a look at the feedback
OpenDDR got compared to other commercial offerings, it was too complex to use.
What you list below is not simple. Here is what I had in mind:
DeviceMapClient client=new DeviceMapClient(true); //the true parameter will
autoload the resources from jar if it exists otherwise the internet
-or-
DeviceMapClient client=new DeviceMapClient();
client.loadFromFolder("/usr/local/data/devicemap");
-or-
DeviceMapClient client=new DeviceMapClient();
client.setDeviceFilePath("/usr/local/data/devicemap/devices.xml");
client.setDeviceFilePatchPath("/usr/local/data/devicemap/devicespatches.xml");
client.setBuilderPath("/usr/local/data/devicemap/builder.xml");
client.load();
-or-
DeviceMapClient client=new DeviceMapClient();
client.setCustomLoader(new CustomLoaderInterface());
With the 4th option, all the code you have below goes into an object which gets
passed into the client and invoked. Personally, I think a *large* amount of our
usage will fall into the 1st and 2nd use case with a small percentage hitting
the 3rd and 4th.
________________________________
From: Radu Cotescu <[email protected]>
To: devicemap-dev <[email protected]>; Reza
<[email protected]>
Sent: Monday, June 24, 2013 2:29 PM
Subject: Re: devicemap java client cleanup
Hi,
Not really. A dev could just feed the DeviceMapClient a configuration map with
InputStreams for the required data sources. Let's not limit ourselves to
thinking only in file system abstractions and allow devs to build their own
logic for loading some data sources.
This is how I thought to modify the DeviceMapClient:
public DeviceMapClient(Map<String, Object> configuration) throws
InitialisationException, IOException {
devices = new HashMap<String, Device>();
patterns = new HashMap<String, Device>();
Loader loader = new Loader();
BufferedReader br;
if (configuration == null || configuration.isEmpty()) {
throw new InitialisationException("Cannot initialise the
DeviceMapClient without a configuration map.");
}
InputStream builderDataSourceIS = (InputStream)
configuration.get(DEVICE_DATA_SOURCE_PROP_NAME);
if (builderDataSourceIS == null) {
throw new
InitialisationException(buildErrorMessageForIS(DEVICE_DATA_SOURCE_PROP_NAME));
}
br = new BufferedReader(new InputStreamReader(builderDataSourceIS));
loader.loadDeviceData(br);
builderDataSourceIS.close();
InputStream builderDataSourcePatchIS = (InputStream)
configuration.get(DEVICE_DATA_SOURCE_PATCH_PROP_NAME);
if (builderDataSourcePatchIS != null) {
br = new BufferedReader(new
InputStreamReader(builderDataSourcePatchIS));
loader.loadDeviceData(br);
builderDataSourcePatchIS.close();
}
loader.setParentAttributes();
InputStream deviceDataSourceIS = (InputStream)
configuration.get(BUILDER_DATA_SOURCE_PROP_NAME);
if (deviceDataSourceIS == null) {
throw new
InitialisationException(buildErrorMessageForIS(BUILDER_DATA_SOURCE_PROP_NAME));
}
br = new BufferedReader(new InputStreamReader(deviceDataSourceIS));
loader.loadDevicePatterns(br);
deviceDataSourceIS.close();
InputStream deviceDataSourcePatchIS = (InputStream)
configuration.get(BUILDER_DATA_SOURCE_PATCH_PROP_NAME);
if (deviceDataSourcePatchIS != null) {
br = new BufferedReader(new
InputStreamReader(deviceDataSourcePatchIS));
loader.loadDevicePatterns(br);
deviceDataSourcePatchIS.close();
}
devices = loader.getDevices();
createIndex();
}
As you can see no one but us has to know the internal logics. A consumer would
just have to provide a configuration object which can be thoroughly documented
regarding its expected values.
Thanks,
Radu
On Mon, Jun 24, 2013 at 9:10 PM, Reza <[email protected]> wrote:
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
