Hmm, I didn't at the time, and can't really remember them at the moment. Being a complete AOLserver newbie at the time I really didn't want to start saying that module X was better than module Y etc. They'd all be built by their authors and solved the problem that they were tackling at the time. That doesn't make any of them right or wrong.
I'll have a snoop around my AOLserver stuff over the weekend and see what I can remember - its going back a good 18 months though :( I can also make my final solution available too but its far from 'finished' and could do with a fair bit of further cleaning up. I never had the time to do that in the past, and haven't been using AOLserver for a while now, so haven't had a pressing need to. Sorry folks :( I'll see if I can put a tarball together of what I had, but there's no guarantee it will work! There are a couple of big questions to be answered or decision to be made in the way it is taken forward namely 1) Is it better to a) take the OpenACS code and change it as little as possible so that future changes to OpenACS can be easily merged in, or ideally have the code shared between OpenACS and AOLserver Or b) take a stable drop of the OpenACS code and remove all of the stuff that is not required for the task in hand and reduce it to the bare minimum needed. The end solution might be a bit 'cleaner' but it would be much harder to take advantages of fixes/changes/improvements made by OpenACS folks. 2) It relies on bits of the OpenACS data structure so requires a database (I've only got it working on postgreSQL) - is this OK for a standalone module or would it be better to abstract that a bit with some API that would let it write to the file system for example instead of a database if so desired. I'm sure there were a few others but they don't spring to mind at the moment Going back to the discussion about the 'something' that might be missing from the AOLserver project: I believe that this is the kind of thing that needs to be driven by the community or some subset of it rather than an individual. Otherwise we'll end up with yet another module that may or may not be any better than any of the alternatives. As a group it would be good to decide something like 'we need a module for sessions that can run across multiple servers, performs really well, performance isn't a big issue it needs to be simple, is in Pure Tcl, is in Pure C, uses the file system, uses the database' etc. or whatever the group criteria are, and then work together to create a generic solution out of the various individual solutions, and making use of all the expertise in the group to make sure that the end result is well built and robust. With solutions like this that are 'standard' and 'endorsed' by the whole community newbies will feel safer using them even if they are not part of the 'core' server distribution. > -----Original Message----- > From: AOLserver Discussion > [mailto:[EMAIL PROTECTED] On Behalf Of Robert Seeger > Sent: 09 February 2005 14:39 > To: [email protected] > Subject: Re: [AOLSERVER] AOLserver facelift. > > Tim, > > Have you released your findings, or considered doing so? > Writing down what you found to be good and bad about each > approach, as well as making your final solution available, > would probably be helpful to others that may find themselves > in that situation. > > Rob Seeger > > Tim Moss wrote on 2/8/2005, 5:01 PM: > > An example: > > > > - When I started using AOLserver I wanted to have user > sessions so I > looked > around at what there is. > > AOLserver itself offers nothing, so I looked around for > modules > > - there's several, some that use files for > storing sessions, some that > use > the database, some that > are in server memory. Some are pure Tcl, some > are > pure > C modules (and not so portable), others are hybrids. > > > > So which one should I use? > > > > There's no information about how or if any of them are > actually being > used, > by how many users, how they > compare performance wise etc. etc. > > > > So I tried them out - some I couldn't get to work, some > wouldn't compile, > some wouldn't scale etc. so my question > was left unanswered. > > > > The solution: > > > > Rip the session code out of OpenACS. It worked, it was > tried and tested > (though not in the 'ripped' form), it > scaled to multiple servers, it was > pure Tcl and so very > portable, it was heavily designed for performance. > > > > > > However, this took a load of time to reach this point and > it would > have been > nice if there was a module providing > all of this the came with the core > AOLserver. > > Sure it wouldn't meet everyone's needs but it would be a > good starting > point > and if its pros and cons were > documented then a developer could weigh > up the > benefits > of using it against writing their own to meet specific > > requirements. > > > > > -- > 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.
