From: Kutter M. <mar...@er...> - 2004-07-20 06:45:14
|
Hi Antti, Hi * ! >> If multi-leveled .ini-style configuration files look appealing to you, >> please respond & I'll post an alternative implementation handling >> unlimited (almost) depth to this list (or to the OI2 patch manager). >I mailed Chris a patch for "unlimited levels" several weeks ago and had >a conversation about the issue. >I understood that Chris has philosophical reasons not to include such >a patch since understanding an ini-file with more than 3 levels of >hashes is hard for a human - and thus hard to write and maintain. I agree with you & Cris that multi-level .ini files are hard to read for humans. Nevertheless, I do not like the idea of having different config file styles with different abilities - I would prefer them to be equal in terms of power. >I really disagreed with the absolute limiting to 3 levels. I understood >his arguments but preferred to let people themselves decide wether >they want to use more than 3 levels. After a while of using my >unlimited-level-ini-parser I have begun to understand his points more >clearly and have converted all our own ini structures to use only two >levels. And I encourage you to do the same if you ever plan to let >anyone else modify your ini files x) Actually, I do not care too much about human-readablity at least for the deeper leveled part of my .ini files. This is due to the fact that I use a custom SPOPS backend that needs some kind of backend description (much like WSDL) with arbitrary complex data structures. My spops.ini files are auto-generated, and the more complex parts are not meant to be edited by hand - so that's no point to me. >There are however some situations where SPOPS object for example can >not be initialized with only 3 levels.. (has_a / links_to relations >with custom key, and your example to name a few). I have understood >that handling of these structures is a bit under construction but >Chris suggested earlier that at least has_a and links_to would follow > the following syntax: >[myspops has_a] >OpenInteract2::MyObject = cystom_key: column_id >I have understood that handling of has_a relations like this is in >the CVS for testing the concept but I myself have not yet had the time >to test it.. According to this syntax the configuration you would >probably end up with would be: >[bla creation_security] >u = WRITE >g = 3: READ >g = 2: WRITE >w = READ >ro g separated as ; : >g = 3: READ; 2: WRITE >This ofcourse does not yet work :) >To help these transformations Chris wrote >OpenInteract2::Config::Initializer class which is used to convert ini >files values to other form upon reading. You can define your own class >for this purpose under [system_class] in server.ini if you wish to do >custom transformations. In my opinion, this solution clobbers the .ini syntax - and it's just one step further and nobody knows how many there are to come in the future. But if a maximum of [section subsection] is intended, that's the only way to go. I don't care about which syntax my config files are - I just want them to be all of the same. And I don't like .pl files too much - they tend to be confused with perl scripts & the syntax is a killer for non-Perl-speakers. Would XML be an option ? XML config files would allow arbitrary levels of complexity. And while XML itself is not easy for humans, there are lots of XML editors which make editing really easy. There are also lots of XML:: modules on CPAN, so implementing a .xml config file parser is not that hard. > - Antti Regards, Martin |