Wedge

Well, the problem's still there, it's still written into law, and just because the ICO is toothless doesn't mean it won't try gumming people for compliance.

If a test case does emerge, though, and the ICO does issue a penalty, it might have an effect...

Yeah, The Register is reporting similar: http://www.theregister.co.uk/2012/05/18/cookie_law_ico/

But the most amusing part is one David Evans, a rep for the ICO...That last part is very interesting... and makes the whole thing basically irrelevant. Argh, so much time wasted, hardly surprising they haven't responded to my email yet.


The best one, though, is a comment in response to that article.

http://forums.theregister.co.uk/post/1414984

I think the scope aspect is a pretty neat idea and have no idea why it wasn't introduced into the core by default. Note that while there is a mod for it, it is modified in sm.org's case and I'd love to see making that at least a little extensible ;)

The quick search defaults based on where you are - if you're in a topic, it defaults to that topic, if you're in a board - default to that board, otherwise search the whole forum.

Now what is it we always tell newbies? :P :lol:

(Remember that search can also work on a single topic ;))

The more drastic solution I've proposed is the one that obliterates all tracking of any kind for non-logged-in users. You lose the ability to see how many guests there are and what they're doing, but you gain a massive performance boost and instant compliance. You also get some SEO benefits to not having to munge the session ID around.

That aside, it would be trivially possible to be absolutely compliant with the rules with almost no work by having the session ID pushed to the URL but that does raise issues for SEO. And you can imagine how many people won't like the idea of not knowing how many 'guests' there are, which means there's a debate on how to judge how active a forum is.

But it would absolutely solve all the problems by then making cookies required only to be logged in, and if you don't agree with that, you don't get to be logged in, simple as.

What I am seeing, though, is sites simply refusing access without cookies and being done with it, such as Games Workshop's site was doing last night when I looked, which is entirely legitimate as I understand it - but it spells doom for search engines.

The initial connection being the hardest is not surprising, because it's doing a bit more than just loading; it's also rejigging the file as well to a point. SQLite is pretty complicated.

I also didn't think it was async behaviour, that would certainly run counter to how PHP works (i.e. it's a blocking behaviour rather than a non blocking one)

Yup, it starts out with less efficiency and will outpace SMF 1 after a while, but it's never clear exactly when the switch will occur.Well... there's part of the problem. Especially on Apache, each PHP request is theoretically meant to be threadsafe and thus independent, so any request made can only use stuff that is outside PHP itself for persistence, whatever form that persistence takes. For big persistence obviously something like MySQL is going to be used, but for short term caching, you'd likely be using memcache or whatever.

Really, it's just about what is available to service the lower end hosting; anyone running Wedge etc. on any really large platform is going to be on a VPS and able to drop memcache or APC into place anyway.Actually it's mostly a toss-up between pure CPU overhead at that point. Either way it's still I/O bound but the scale of writing means whether you write 1KB or 8KB is almost irrelevant, so it comes down to the file_put_contents overhead or the overhead of SQLite which is effectively also a native method. That was the thing nend's experiments came up with, that at times one was faster than the other but it was variable - and from what I can see the variation is going to ultimately be down to CPU and file overhead between the two. (The fact that the SQLite implementation was slower to start with is no surprise to me, any system with any kind of caching performs less efficiently from cold.)Something like that. If you want $settings cacheable with a proper cache, the underlying settings have to be moved out of $settings and available globally. We're only talking 2 variables IIRC, so it's not a massive deal.

But the question of expiry is a bit more tricky to resolve.It sort of is, and that's sort of what the patches do, but if you have a site like that you may not wish to clear the entire cache, just parts of it.