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)