存储与应用程序捆绑在一起的静态数据的最佳方法是什么？

Question

I'm writing an application in java that will facilitate creating wireless sensor networks using off the shelf micro controllers, sensors, and radios. Each sensor and radio will most likely require unique code. I'm planning on creating skeletons for each platform and and then having modular bits of code for each sensor and radio that can be plugged into these skeletons. This will result in a library of static information that will be used to dynamically generate code for these sensors.

I'm not sure what the best way to store and organize this data would be. I started off trying to create classes for each sensor encapsulating its unique properties but using objects for data storage only seems weird. I feel like SQL would be overkill as the data isn't really changing and I would also like to keep everything in version control. Should I just use flat files? XML? Any advice on how to architect this project would be very welcome.

Answer 1

Instead of generating source, I'd go binary. Conceptually, that is.

Why would the source code need to change if a device is plugged in or out? Simply compile binary device driver libraries and link them to the main app. There is an assembler, so likely there is a linker.

If there is no linker, and you are forced to use a monolithic source file, then at least we can use the concepts of a linker.

Linking Source Code

For inspiration and details I'd look into Operating System Design a little bit, for the concepts of device drivers , and IO devices , and network sockets . I'd use this to take a hard look at the source that would be generated, and what exactly changes if a device is changed, and fix it so that as little as possible, ideally nothing, has to be changed.

The code for the app running on the (presumably embedded) system should be maintained separate from the device drivers, so here is where the abstraction needs to begin. It needs to be refactored to abstract away the particulars of the devices into abstract device classes .

So this is the first step: refactor the generated source to abstract out the particulars of the device drivers so that you have a main application that calls functions via symbols .

This allows the main app to work regardless of the number and kind of devices available.

Next, I'd look into compiler theory , particularly the concepts of symbol resolution and static/dynamic linking , and stub . Since the generated source is refactored so that there is a main application and a list of device drivers, all that is left is to make the devices available to the application.

Illustration

The application could generate the source code to be assembled by concatenating the source for the main application with the source for the device drivers.

It would provide a stub as well: a small library providing a function to iterate the devices and interrogate their classes.

Your application then becomes so simple that a one-liner on a *NIX prompt could do it. No Java required:

cat program stub drivers/foo drivers/bar > generated-source-or-binary

In it's simplest form, the program would contain a call to an iterate_devices label in stub .

Here's a layout of the source and/or binary image:

// application
main() {
   for ( device in list_devices() ) {
      switch ( device.class ) {
         ....
      }
   }
}

// stub
list_devices() {
   for ( device = first; device != null; device += *cur )
      yield device;       
}
first: // drivers follow

// drivers/foo
dev_foo: .long dev_foo_end - . // size
....
dev_foo_end

// drivers/bar
dev_bar: .long dev_bar_end - .
....
dev_bar_end

Organizing Driver Sources

This shouldn't have to be more complicated than a directory with files.

A simple approach would be to include these in the .jar in a specific package. For instance, having a class provide driver sources like this:

package myapp.drivers;
public class DriverSource {
    public static InputStream getDriverSource( String identifier ) {
        return this.getClass().getClassLoader().getResourceAsStream(
           this.getClass().getPackage().getName().replace('.', '/')
           + '/' + identifier + '.source'
        );
    }
}

would require the driver sources to be put in myapp/drivers/{identifier}.source . In a standard eclipse project, you'd place the files in src/myapp/drivers/ . Using Maven, you'd put them in src/main/resources/myapp/drivers/ . You can also put them in another directory, as long as they are copied as resources to the proper package directory.

The above class could also serve as a basis for more complex storage: you could query a remote service and download the source files, or query an SQL database. But resource files will be a decent start.