Therefore, design your server code to be free of user information. Store user preferences in cookies. Where possible, minimize cosmetic customization options, both saving on cookie-space and decreasing the time a user must spend rebuilding their cookie on separate machines.
A related, but stronger, concept is CacheableCustomizability.
Just a quickie page; if it's elsewhere already and I missed it, please let me know.
I write this page mainly because I'm going to bring it to MeatballWiki: no more server-side preference storage. (The space used is ridiculous.) That means no more password system, which didn't really make sense anyway. I'm not aware of any drawbacks, but if anyone else is, this is the place to mention them.
While I'm at it, I'll probably also add the UserName field to the edit page, to make logging on easier when one's doing a quick edit. Also, is there a compelling reason to keep the "100% wide edit area" and "no Random Page link" preferences? Removing the Preferences link from the linkbar entirely would be my ideal goal; the only drawback would be loss of the "no linkbar on top" option, which I imagine is rather handy on LynxBrowser. -- ChrisPurcell
IIRC the main problem with UseMod user preferences storage is, that there are two cases that assign storage space but shouldn't: (1) cookies are off (2) user looks into preferences but doesn't store them. These situations lead to a perhaps 10-20x increase in storage space. What one can do is delete "userpref files" that are initialized but never written to (finde them on their file size). One can do it in a cron job as part of server housekeeping. This doesn't solve the fundamental problem but at least takes the sting of it. Just my $0.02. To put all pref information into the cookie creates a large overhead because cookie info is transferred on any single request. -- HelmutLeitner
It's always a trade-off depending on personal priorities. Having the data on the client side has advantages and disadvantages. For example: (1) you can never use preferences to hold significantly more data, for example a list of pages for notifications (2) you must be much more careful about data structures and changes to it (3) you have no access to informations about clients (4) you have lost a unique key to separate client access (e. g. from the same IP). I do not say that this is important or that server side is better than client side. I just think that the bad UseMod userpref storage allocation method (which could be changed easily), should not be the prime reason for this design decision. -- HelmutLeitner
I think our current UserPreferences? don't need to be stored on the server side, as long as we put the ControlsByControlled?. The task of getting rid of them would be a valuable exercise. We may want to reintroduce them later. -- SunirShah
I've finished making MeatballWiki a UserFreeServer. The hardest problem was understanding how and when the current functions were called, in order to send the Cookie HTTP header when appropriate. Interestingly, the code size has now dropped from 5061 lines to 4725. FeatureKarma?
The code's now live on the mainstream site. I had the public beta up for a month, so everyone had ages to check it out. I absolve myself of any guilt if people now find bugs
_^.^_ -- ChrisPurcell
I'm starting to notice dramatic improvements in performance that I'm sure are related to the great work you are doing here, in general, and (I suspect) to this UserFreeServer implementation, in particular. Thank you very much for making meatball an even more pleasant experience. -- HansWobbe