Re: [vos-d] revamping vosapp config files

[Reed Hedges]

Yes, this is a good idea. Terangreal could use the same mechanism (it already
stores preferences in properties but does not save them).

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

Maybe we need a version of COD that is plain text? (Also useful for Terangreal's
config file)

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

I think we can expand the feature for multiple command line arguments easily.  
This is a very useful feature of vosapp, since it takes care of one of the
most annoying aspects of making a command line app.

For environment variables, you just need to parse the value of the variable:

VOSAPP_COD_FILES="file1.cod file2.cod \"file 3.cod\" file\ 4.cod"

or do something like this:

VOSAPP_COD_FILE_1="file1.cod"
VOSAPP_COD_FILE_2="file2.cod"
...

Reed

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

[vos-d] revamping vosapp config files

[Peter Amstutz]

-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

  
  File blacksun.cod
  

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