Pointers: Device configuration schemas in XML?

This has to be a FAQ, but has anyone developed a good schema for having a device present an arbitrary list of configurable options (probably in XML) to a UI that presents the configuration options according to its own UI rules?

At its simplest, this might be something like I show below, for a device with two configurable options; one that has 3 discrete options, the other of which being a setting from 0-255. The UI might present Feature 1 as a set of 3 mutually exclusive radiobuttons, or as a drop- down list; it might present Feature 2 as a slider bar, or as a type-in numeric field, or both. The UI isn't the concern here - I'm looking for existing work in storing and presenting the /contents/ of the UI. The example is very simple, but how does one handle, for instance, two separate features that are linked (e.g if I set Feature 1 to Discrete Setting #2, then Feature 2 gets limited to 127 maximum?). I can think of many ways to do it but I have to think this problem has been solved a million times before and I don't want to reinvent the wheel. I don't think UPnP's system went down to the level of detail I require but I'd be happy to be told I'm wrong.

Example of what I mean:

Feature 1

Discrete Setting #1 Discrete Setting #2 Discrete Setting #3

Feature 2

0 255 1
Reply to
Loading thread data ...

Similar to XML, but perhaps a bit easier to read and parse I prefer a JSON like scripting language (for example):

t_Config server { user : rob server : xyzzy socket : 2222 dir_run : /u0/Meta/run file_pid : bLobStor.pid }

t_Config blobStore { dir_config : /u0/Meta/BlobStor.conf db_meta : /u0/Meta/BlobStor.meta filestore : [ /u0/Data/a /u0/Data/b /u0/Data/c /u0/Data/d /u0/Data/e ] }

This still gives key/value pairs, and the values can be [ lists of items ] ... Parsing takes about 20 lines of C code ... then a thin API can be used to get the values at runtime:

opt_init( config.cfg ) ;

str = opt_get_str( "filestore", 0 ) ; fs_list = opt_get_lst( "filestore" ) ; socket = opt_get_int( "socket" ) ; server = opt_get_str( "server" ) ;

One implementation note: write a wrapper around strsep() which parses your blob or input stream, and returns a list of values, including "quote strings" or 'quoted strings' as a single item.

Simplifies life greatly (assumes C).

HTH, Rob Sciuk

Reply to

You might explore how Jaluna approached this. IIRC, Jaluna 1 is still "open"

Reply to
D Yuniskis

What I'm missing here is how this solves the interdependence problems. What you showed there seemed to me to be very similar to what I showed in the example - gives you a description of the full range of each control, but doesn't let you disable or limit specific settings based on other current settings.

Did I miss something?

Reply to

No, my brain-fart, sorry.

Still, if you are trying to associate one control to another in the config file, you'll ultimately have to essentially impement a domain specific language.

As an analogy, I also implemented database triggers in the base language, and these perform in a manner somewhat similar to what you describe ... though in my trivial case, they simply generate the SQL/DDL to create a trigger upon a database table to do the heavy lifting ... here's an example:

t_Trigger Castor.ins_filTable { source : filTable target : wrkTable action : insert when : after insert : [ Added new.device new.inode ] }

t_Trigger Castor.upd_filTable { source : filTable when : after action : update vars : hash target : wrkTable insert : [ Modified old.device old.inode ] }

t_Trigger Castor.upd_genfile { source : filTable when : after action : update vars : [ mtime hash osize ] target : filGen insert : [ old.device old.inode old.mtime old.hash old.osize ] }

In your case, you'd simply have to define conditionals which would modify the attributes of the target device.

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.