Original posting on AOLserver mailing list:

 (...)
 
 Previously (with 3.4) I've been using the following:
 
 1/ code that allowed dynamic loading of "packages";
 The code that was contained in it's own namespace and was loaded/unloaded on demand with reloading on changes.
 
 2/ nsdqe provided session handling - setting the cookie and using ns_set for data plus serialization to harddrive
 This was handling all the session stuff plus logging in/logging out.
 
 3/ nscache and similar code to handle cache'ing
 
 This seems to work ok, but for generic approach what I really lack is an OO - ie so that someone could develop a generic "ecommerce"
 class and inherit for specific implementations. This can be done writing plain procs and passing proper args/configuration 
 variables, but I find this task a job for actual OO.
 
 This also has a downside that ns_cache cannot actually cache Tcl_Obj so if I would get a result from the db this would get 
 serialized to a string and deserialized on first use. I did develop some cache mechanism that does "deepcopy" of the objects and 
 then caches the Tcl_Obj themselves for each thread, this improved the speed a lot.
 
 Right now I'm wondering the pros and cons of the following solution (using 4.0.10, 8.4.12, thread 2.6.3 and some other extensions).
 
 1/ similar code, but one that would initialize a separate thread for each package and load all the neccessary code in there - the 
 package code would be Itcl classes and plain Tcl code
 (in the future this could use VFS and maybe tbcload to allow redistribution of the code)
 
 2/ session mechanism (which would require sessions to initialize main website engine) that would create instance of an application 
 object per each session - so that each user would be an instance
 
 3/ most data would be cached using Tcl_Objs (maybe even not using nscache)
 
 4/ Background jobs could also use the same thread, using common non-AOLserver methods (after/fileevent etc)
 
 The objects would allow serialization/deserialization by supplying name-value data that would be saved by the session manager. 
 Session would only allow X number of concurrent sessions and serialize+delete the oldest ones when new ones need to be created.
 
 Pros:
 
 * much better app designing framework
 
 * using event loop for packages
 
 * one thread per package would solve most multi user scenarios
 
 Cons:
 
 * any change in the package code would require serializing all instances and reloading the package
  (but it's not common to experiment with on production servers)
 
 * non-session aware browsers will not be able to use most of the functionality
  (some functionality could be done by supplying a generic instance for all non-session aware)
 
 * it would be easy to do a DoS by generating a lot of sessions
  (since serialization/deserialization would take a lot of time)
 
 * sync DB operations could cause a freeze for many customers (especially with long lasting queries)