Re: [Openinteract-dev] example of new server.ini @INCLUDE syntax

[Salve J N. <sal...@me...>]

Chris Winters wrote:
> Salve J. Nilsen wrote:
>> 
>> * Package-related config should be placed somewhere very close, but
>>   seperatly from the server config (e.g. the "fulltext" package
>>   config has IMHO nothing to do in the conf/server.ini file, and the
>>   base_user action.ini files are too far away in pkg/base_user/conf.)
>>   I'd like to suggest that all package config files are accessible
>>   from a suitable "package.d" directory (e.g.
>>   "conf/packages.d/fulltext.ini"), and that the main config file
>>   @INCLUDEs these en-masse. The conf/packages.d/*.ini files need not
>>   to be more than symlinks to the packages in order to get a positive
>>   effect.
> 
> That's a really interesting idea. With the global package
> configuration override file I've tried to keep everything in one
> place, but the global override stuff is probably too confusing for
> most people to use. (Then again, most people probably don't need to
> modify their package/SPOPS configurations either.)
> 
> The other part we have to balance is package upgrades -- how to allow
> the user to keep any changes she's made with the potentially new
> package configuration? Maybe with a package upgrade we read in the
> existing configurations and compare them to the new ones, writing out
> any differences to a separate file?
> 
> I don't think we can do symlinks (not cross-platform), but I like the
> idea of keeping all the SPOPS + Action data in one location....

How about using a file that just contain the following lines?

=======8<----< $OPENINTERACT2/conf/packages.d/my_package.ini >-------

# This is a OI2 config file, belonging to the OI2 package referenced to
# below. See the package config files in that directory for more
# information.

@INCLUDE = $OPENINTERACT2/pkg/my_package-0.01/conf.d

-------------->8=====================================================


>> * When upgrading some software (OI2 or .zip packages,) I'd like to 
>> keep my old config, but still get the new features. Splitting up
>> files (as you described) may help with this, so do place commonly
>> changed config entries in one or more seperate files.
> 
> OI2 should never, never overwrite your server.ini file with an
> upgrade. Once we write it at server creation we don't touch it. (In
> fact we don't touch anything in conf/ except for repository.ini.)

Hm. In that case, there's not much reason for splitting up files, right? 
We should now only be left with the problem of "how to keep all 
configuration close together".

>> * BTW, I'd like to keep my timezone when I upgrade the server. :)
> 
> This shouldn't get overwritten. Does it?

It doesn't. I assumed (in error) it was the server.ini file you wanted 
to be able to change.

But anyway (somewhat unrelated to this) I _do_ have a problem with the 
timezone enry in server.ini, but only because it is so closely placed to 
the CVS revision string in the file (making my patch to that config file 
fail every time server.ini gets updated in CVS. :)


>> * s/server_action_info.ini/server_actions.ini/g (Naming consistency
>>   is good. :)
> 
> Actually 'server_actions.ini' was my first name but I thought it
> implied that you'd actually find actions there, which isn't true.

Oh. Hm. I got confused by the [box] definition in 
server_action_info.ini, where it says

=========================8<--------------------

[box]
action             = box_display
default_template   = base_box::main_box_shell

# ....

--------------------->8=========================

Should it say "use_action", "bind_action" or something other, less 
confusing then "action"?

(See! I'm showing off my ignorance! :)


>> * The ini file parser should warn about inconsistencies and
>> duplicate entries if they're not allowed.
> 
> 
> Dupes we can do. Inconsistencies maybe not. But I'd imagine
> duplicated configuration would be the main problem.

How about checking for legal keywords? IIRC, some config file parsers on 
CPAN force you to define which keywords and/or value types are legal in 
a given file. Would that be sensible for OI2?


- Salve

-- 
Salve J. Nilsen <salvejn at met dot no> / Systems Developer
Norwegian Meteorological Institute           http://met.no/
Information Technology Department / Section for Development