On 16 Sep 2002 at 23:16, David A. Desrosiers wrote:
> I'm not sure how hard it would be for the python tools and the
> other bits to parse nested blocks, or options nested within opening and
> closing tags, but that's one approach also. Something like:
>
> <plucker_desktop>
> update_enabled = 0
> update_frequency = 1
> update_period = daily
> update_base = 2002-09-08T12:57:15
> close_on_exit = 0
> close_on_error = 0
> </plucker_desktop>
I certainly agree on using a single .ini/rc, as otherwise it gets too crazy to try to
manage
options.
For sections, there is a [PLUCKER_DESKTOP] section that sets switches for the program
that are
only relevant to it (position of a last window save, etc).
Keys used inside a channel section are there for other tools to use also. update_base
is pretty
generic, if there was another tool, plucker-foo, to manage update times, they are
going to need
the same set of keys and it would be somewhat confusing to have the plucker-foo keys
want to
read/write <plucker_desktop> keys. It makes the keys a bit more seemless if the
reusable ones
are available to be global, and it is tough to know in advance what will be needed in
the
future. For example, "user" key was created by Dirk for RunSync.exe to install; when
it was
time to pick a key for installing graphically, can just reuse the existing key in a
new way.
For run-ins of keys, I think good documentation of the config file is good enough.
Someone
making a new tool can look at what keys already exist, and use the ones that address
the
current problem (as time goes on, more and more problems will already have been
solved, so can
just reuse the existing keys). If there isn't a key to fit, drop an RFC on plucker-dev
about
it, pick a key name and use it, (which has been done in the past quite well).
I do like the arrangement of keys to group them into sets for readability, but we do
that in
the commented .ini/.rc file anyways with just some comment spaces between the groups
of things.
A full-on XML file config wouldn't be too bad for a later date, as we discussed some
months
back. There are 2 keys that would be useful to have attributes to describe a channel,
the user
installations and integrated exclusion list.
<users>
<user="Robert O'Connor" install-to-card="Yes" />
<user="Cindy Joe" install-to-card="No" />
</users>
and
<exclusion-list>
<exclusion="http://.*x10.*"; action="exclude" priority="1" />
...and so on.
</exclusion-list>
That isn't a feasibily a Plucker 1.2 possibility though.
The only problem in that it is somewhat difficult to then keep things on the
command-line the
same as the config file. Using separate keys keeps it easier to type into the command
line:
--exclusion1=http://.*x10.*;-;1 --exclusion2=http://.*;+;0
Commandline arguments are a good way to keep available for other future tools to use.
For
example, can run a browser plugin for adding a channel to manage, by just calling a
commandline
on it and terminating, instead of juggling file drops, IPC, etc.
Best wishes,
Robert
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
