Dossy, Would it work to have a system config and an instance config? Consider it the way some unix programs have a system configuration file which sets up the default values for many things... and a configuration file per user that sets up things for that user.
To add to this, each module could have it's own "default config file", stored in the directory holding the module I would think, which would define it's defaults. These values, too, could be overriden in the server-specific configuration. The only issue I can think of would be that there would need to be a way to setup configuration options for modules that may or may not be loaded, which I'm not sure is possible at the moment. Robert Seeger Dossy Shiobara wrote on 2/8/2005, 6:21 PM: > > It is a neat idea - I'd personally take it further and put all the > > defaults are in the config file and suggest that the server errors > > without them rather than having them hardcoded hidden away in the C > > code. > > (Sane) defaults are nice. It allows for sites to go through upgrades > without having to do a lot of configuration file management. > > But then, in past lives, I was the sole sysadmin of over 100+ hosts, so > I really appreciate designs that minimize effort on the admin. to > maintain and operate ... > > However, I do agree that there needs to be an updated Admin. Guide that > documents all the various knobs and switches that can be manipulated. > Who's up for that task? :-) > > > > > 7. Release more code. For a specific example of what I am talking > > > > about, consider the NV: network variable. For _years_ I have been > > > > inquiring about NVs, since Jim Davidson mentioned that they are > > > > used by AOL. An NV is simply shared data, available to multiple > > > > physical servers, a networked nsv, I suppose, but maybe more. This > > > > would serve the same essential purpose of a javabean I think. > > > > Hear hear! This is the kind of generic extremely useful code that AOL > > must have lying about that is unlikely in itself to be a trade secret, > > but would be of huge assistance to the community developers. > > Actually, it turns out that the AOLserver implementation of NV could > very well have been patentable when it was first designed and > implemented. I don't know true this is, but it's something to consider > carefully. > > It's also a concern that many open source projects seem to be completely > oblivious to: accepting contributions can be dangerous, if it implements > functionality that somehow violates someone else's patent or otherwise > protected intellectual property. As frivolous as the SCO vs. Everyone > lawsuit may seem at the surface, it's a real threat and I imagine most > open source projects don't have the money for the necessary legal > counsel needed to defend against such threats. > > > That's not a good argument to use. > > If one has a choice between some code that will handle X thousand > > requests/users/whatever and some that is known to handle X million > > requests/users/whatever, which would you prefere to use even if you > > don't need that capacity right now? > > Do you live in a 32-bedroom mansion all by yourself? Do you drive an > 18-wheeler truck to commute to your corporate job? > > There's an inherent beauty in right-sized solutions. > > > Start completely from scratch > > Or > > Start from stock OpenACS > > > > I personally wanted something in-between and there wasn't anything > > I suspect I'm not alone. > > Did you publish what you've developed from scratch? Put a OSI-approved > license on it (preferably the AOLserver Public License) and lets declare > it the in-between solution. > > That doesn't solve the real problem ... > > -- Dossy > > -- > Dossy Shiobara mail: [EMAIL PROTECTED] > Panoptic Computer Network web: http://www.panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
