UserFreeServer

MeatballWiki | RecentChanges | Random Page | Indices | Categories

A typical website will see thousands of people come and go, and can have no knowledge of whether they plan on returning, or are gone for good. Users will also tend to forget their old information and start afresh. Private information about visitors and members, such as customization details, will therefore build up over time into an ugly space-wasting mess.

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

: Death to the UserPreferences? page. A related pattern is ControlsByControlled? (i.e. put controls by the things they control). -- SunirShah

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

: To store all the information on server creates another overhead, because the server must look it up each time, instead of the client (who has it handy). Is sending a few text strings in the HTTP header even noticeable on most connections - even a 32K modem - compared with network latency, server runtime, and page sizes? -- ChrisPurcell

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

: Notifications, I agree with - not possible with cookies. This also holds for things like WikiPedia's SubscribedChanges/watch-lists. But for the average-Joe server - and usemod.com is not backed by a behemoth - storing all that data is a great imposition. -- ChrisPurcell

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

Chris...

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

Chris, nice work! I feel lucky to understand this implementation of your work. :-) Best, MarkDilley

CategoryWikiTechnology

UserFreeServer

Discussion