-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all. I'm still alive :-) Not much time for hacking, but trying to make the most of the little time I do have.


I'm currently in the process of rewriting all the parsers in VOS to use the boost::spirit framework. This will eliminate the dependency on external tools (flex and bison) which have been a stumbling block for a lot of people trying to compile VOS.

The next parser to rewrite is the vosapp config file parser. The vosapp framework can be used by any VOS program to provide configuration and plugin support. Primarily is it used by omnivos (in fact Omnivos is really just a main() that calls into vosapp).

Here's a sample configuration file:

  LogFile 3dworld-bs.log

  LoadModule plugins/.libs/libomniplg_search.so

  <LoadModule plugins/.libs/libomniplg_cod.so>
      File blacksun.cod
  </LoadModule>

Pretty simple, the format is key/value pairs, with a special LoadModule block that loads a shared object and provides it with specific parameters. It is deliberately modeled after the Apache configuration language.

Under the current implementation, the keys are stored in a map, so they can only appear once. This is a problem, since it means for example you can't list several COD files to load by the COD plugin.

Also, it occurred to me that it's sort of silly that VOS is intended as sort of a universal data structure, but we're loading the configuration as a separate data collection.

So my proposal is to have configuration files load into a /configuration vobject in the local default site, with each module's paramaters stored in a child vobject. Each key/value pair would be stored as a property vobject. Since the child list is an associative array, a key can show up more than once. This neatly solves the problem of duplicate keys. So for modules where it makes sense, it can process the child list in order with some kind of structure. For modules that only need a single value, it can just access that one value.

This would also mean that if the module added a listener to the vobjects in the configuration tree, it could be reconfigured on the fly. It would also be possible to dump the configuration to a COD file and reload it.

I should mention one neat ability of the current (old) system that would have to be dropped is the ability to set configuration paramaters via environment variables and the command line. There is a well-defined format for each parameter, for example, the "File" parameter in the COD Module is --cod-file=... on the command line and VOSAPP_COD_FILE=... in the environment. I don't think we can keep this feature if we decide to allow options to show up more than once in the configuration, and for it to be order-sensitive.

Thoughts?

I'm going to start working on this this week, hopefully.

[   Peter Amstutz   ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDUw+xaeHUyhjCHfcRAve/AKCa20Uku9n2uGWvElrYMmv6lydNLQCeIYiR
vLFxtfkNz+T0BdMrfO86KRY=
=ir5T
-----END PGP SIGNATURE-----


_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

Reply via email to