-----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
