Re: IMPORTANT: your message to public-html

>On Mon, 22 Oct 2007 19:32:59 +0200, Brian Bober
>> 3rd-party content vendors who need to store simple preferences (such as
>> "show playback bar") across a huge slew of domains which use their
>> services have to currently store preferences on the server-side, which
>> is very
>> expensive, or otherwisepoor user-experience will result because
>The cross-site XMLHttpRequest extensions for XMLHttpRequest level 2
>discussed on
might help with that. You wouldn't have
>client-side storage, but you would be able to fetch preferences from a
>single server.

Hi Anne,

Thanks, however that isn't a very scalable solution for this
particular limitation
the server hardware necessary to store user preferences across millions of hits
a day is prohibitively expensive when user preferences should be completely
handled on the client-side since it distributes the load. The end result is that
certain things on the internet would be cheaper if handled on the
client side, and
thus advanced funcationality becomes available to more web developers
beyond those
that can afford a server farm. It seems unecessary to build server
farms in order
to handle per-user settings that don't give away personal information (such as
"Do I want X in 10pt or 12pt font?". However, purchasing a certificate
is affordable
to most people. The code the company I work for develops gets hit 10s
of millions of
times per day and thus we can only afford to store user preferences on
a per-domain
basis for most things, when really a lot of these settings should be
stored globally.
Therefore, we're forced to do something less optimal for the user
simply to save money.

I think cert-based local storage should be investigated as part of the
standard, however
I'm not enough of a security expert to suggest what would work.


Received on Tuesday, 13 November 2007 04:27:23 UTC