[admin (no pm's please)]

I can't quite believe this one, and it may be something that was only a problem with Firefox3 and the way cookies are stored there, but....

Cookies have a 4kb limit, if as phpbb2 does (going to check phpbb3 in a minute) you try and track 150 topics for read/unread status, then the cookie won't get reset eventually, it will just sit there as it was from months back. This is because more then 138 topics is more than 4kb...

[admin (no pm's please)]

To state the obvious here, if because of this bug your cookies were wrong, this is not going to instantly and magically mean the cookies now know what you have actually read. However it should start recording correctly from now on.

[admin (no pm's please)]

phpbb3 generally does server side tracking, but the code when using cookies says:

[admin (no pm's please)]

It is also scary to note that even at 4kb that is pretty much 1 seconds worth of data uploaded each time you access a page via dialup  

How many topics do we really need this info on?

[admin (no pm's please)]

It really does strike me that this cookie is a prime candidate for specific compression techniques.

Currently we have on downsizer 138 topics in 4Kb. I reckon doing that in 1kb may be nearly within reach.

Any bets?

[admin (no pm's please)]

I'm calling it a night on this, but an unrealistically small test, just reduced a cookie size from 101 bytes to 34 bytes.

The code to do that was quick and simple, and uses mostly inbuilt php functions, the next step would I think hit the target, but at the cost of a lot of speed and simplicity. Not worth it.

[admin (no pm's please)]

With the bugs out, and by dealing with the fact that cookies store certain characters badly anyway, the working code seems to do better than 25%

I aim to go live with this on downsizer shortly, and then introduce it on myff.

[admin (no pm's please)]

I currently have downsizer producing both cookies so I can validate that they decode identically.

They keep doing so at under 23% of the original size. I am going to wait till the wee hours when no one is on to make it fully live though, as aside from anything else there will be a WSOD for anyone viewing a topic mid update.

[admin (no pm's please)]

In and seemingly working, this effected search,index,viewtopic and viewforum and viewforum reads the cookie twice. I guess tomorrow I may see reports of any other oddities like that. This is probably a Saturday morning change, though I am impatient to get it in.
It's a small think but will again mark us out from other phpbb2 forums systems, adding just a bit more speed and reliability.

[admin (no pm's please)]

Speaking of speed I was a little concerned about the speed of the new code, as optimized it takes a bit less than 2/1000 of a second to deserialiaze the cookie, that ain't good But for someone with a full cookie, they would have had to upload it at 15mbs+ to do better with the raw cookie.
That is not going to happen by and large    It does show a bit of a point though The deserialization is written in php, php as an awfully slow language. Were that code the same raw 'c' code as the standard deserialize then despite the extra complexity, the time taken would be so small as to be hard to measure.