> -----Original Message----- > From: AOLserver Discussion > [mailto:[EMAIL PROTECTED] On Behalf Of Dossy Shiobara > Sent: 08 February 2005 23:21 > To: [email protected] > Subject: Re: [AOLSERVER] AOLserver facelift. > > On 2005.02.08, Tim Moss <[EMAIL PROTECTED]> wrote: > > > If someone is offering to donate freely, commercial-grade > hosting on > > > AOLserver, please contact me. > > > > Surely AOL could provide this as a way of thanking the > efforts of the > > community developers? > > The downside of this is that no one from outside of AOL could > ever get access to make changes to the site, because of the > way security is set up.
I see - I can imagin there'd be a lot of red tap involved getting anything like this sactioned by the security folks. What if the site were pulled out of CVS once sanity checked? > Right now, anyone inside or outside of AOL can make changes > to the aolserver.com site if they're a project member of the > AOLserver SourceForge project because aolserver.com is also > hosted at SourceForge. Yep point taken - 'tis a shame that the aolserver.com site isn't its own example site running on AOLserver itself. Is there anyone within soruceforge that could be contacted to help arrange such a setup? > > I did precisely this some time ago and published the > results on this > > list. Guess what - sample-config.tcl came back more or less > > unchanged. > > What were your expectations? I sort of expected some sanity checking by some of the resident experts of the new config.tcl file I provided (it was around 4.03 I think) and included examples of setting up vservers which were confusing folks at the time). I then expected some discussion on the list if anyone cared and once some form of agreement was reached (either through debate or silence) sample-config.tcl to be updated with anything useful. The silence was the only thing that happened > What needs to happen for your expectations to be met? Some of the above! > Am I the only one who can do the necessary? Probably not - changes to something like sample-config.tcl need to be considered generally useful and helpful, so it probably needs discussion agreement. But maybe the way to stimulate that is to go ahead an make the changes and be prepared for a few flames afterwards > What can I do to delegate the necessary authority to enable to you to self-serve your expectations? I think someone of some group of people need to take ideas/suggestions etc. and drive them forward so that they don't just end up as random patches on sourceforge than ultimately wither and die > I think that's going to be my motto for 2005: "What can I do to enable you to self-serve your expectations?" Hehe - sounds like the way forward for an easier life for someone! > (Sane) defaults are nice. It allows for sites to go through > upgrades without having to do a lot of configuration file management. Well maybe a 2 tier config system should be the standard defaults.tcl that contains all the (sane) defaults and is recommended not be altered on a particular installation, with a second file e.g. site-defaults.tcl for an admin to override defaults at will. That way after upgrades etc. defaults.tcl gets updated from CVS, site-defaults.tcl stays largely the same, unless addiitonal new parameters need to be overridden. Might help keep change management low. Other thoughts on this area would be: - to allow retrieving config from a DB of some sort or another - shipping a web GUI for producing a config file from the defaults plus any changes made via the GUI - allowing changes to config post startup - nice ways of having some common config (for a farm of servers) and some host specific stuff > 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? :-) What I did previously is here http://site-speed.com/aolserver/sample_nsd.tcl - its out of date though (about 4.04 I think) but has some commentary for most of the knobs and switches. > > > > 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. Fair enough - the above may have been a bad example - surely not all of the code at AOL is patentable - surely some of it is generic enough to be useful to lots of people and not specific enough to be a 'trade secret' of any sort > 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. Yep tricky ground - I hope this kind of fear doesn't stunt the development of open source development Society is sadly becoming more and more litiginous > > 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? Hehe - if only! > Do you drive an 18-wheeler truck to commute to your corporate job? No - a crazy sports car for a 10 minute journey! > There's an inherent beauty in right-sized solutions. Don't get me wrong - I'm completely for right-sized. At the moment we don't have that choice - we've got some very basic samples/defaults alongside some very complex ones and little or no discussion/information/acknowledgement of what they are appropriate for and why > > > 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? I started down that route and got as far as getting some interest from a few parties on the list, but due to a change in jobs never got as far as getting what I'd developed to a publishable state; yes it worked but needed a bunch of cleaning up - I ran out of time to do this. To be maintainable in any practical way would need buy-in from the OpenACS community (moving out stuff only they need so that the more generic/basic stuff could be co-maintained without breaking OpenACS or the basic addons to core AOLserver) I definitely didn't have the time to try and organize this! I suspect that maybe some of the above is the reason why there isn't so much code published. It'll typically be developed from scratch for a specific need, and changing this after the fact to a more generic version that's of use to a wider audience can be a fair bit of extra work. > Put a OSI-approved license on it (preferably the AOLserver Public License) and lets declare it the in-between solution. I'm more than happy to hand over a bunch of files to someone who can check the appropriate licence is included (so as not to infringe upon any OpenACS licensing), but that's only the start of it as mentioned above. > That doesn't solve the real problem ... Which is? :-) Tim -- 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.
