Sam said:
I just created a simple class with 20 integers, 20 floats, and 20 strings of 48 characters each. Pickled, the object was 1358 characters long, and run through zlib.compress, it was all of 382 bytes long. That is an awful lot of data for only taking up less than 10% (compressed) of the available storage in a cookie. Fill a file with 4000 characters and see just how much stuff that is. You could also potentially work out a mechanism so that the object gets split across multiple cookies if it is too large. I don't think any browser has a limit on the number of cookies settable by one site. I have attached my goofy test class, just so you can see what it looked like. It probably isn't the cleanest solution, but it can certainly be made to work. I think most applications wouldn't even need the compression step. I've never actually used the CSM, just codeit's Session product, so perhaps I am barking up the wrong tree... --sam --
Cool... IIRC, 20 cookies per site can be set. The question is this (assuming you split across data cookies): over a 28.8k link, do you want to wait at most 80K of data to be sent back and forth from the server on each request which sets session data? In most cases, it would be drastically less, of course. I could see this as a really cool session data manager... it's a little twisted, but it'd be fun. If you're at all interested, Sam, the sdm interface is well-defined.