You can't store much data in cookies and thus you're only shooting yourself
in the foot with a bb gun. 5mb means you're shooting yourself in the foot
with a real gun. And if you're allowing over 5mb, it's a bazooka.
Anyway, I've written extensively about this many times on many different
lists.
On Fri, Jun 3, 2011 at 1:40 AM, Jeremy Orlow jor...@chromium.org wrote:
You can't store much data in cookies and thus you're only shooting yourself
in the foot with a bb gun. 5mb means you're shooting yourself in the foot
with a real gun. And if you're allowing over 5mb, it's a bazooka.
Does anyone have an opinion on this Web Storage spec bug? The input of the
WebKit community is desired. And probably Safari and Chrome folks in
particular, if opinions differ.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that
I'm concerned that implementing this will only encourage more use of
localStorage. The API is very poor because it requires synchronous IO and
synchronization between browser contexts, which may live on different
threads. (Note: Chrome does not implement the required synchronization.)
If we
I'd advise commenting right in the w3c bugzilla, but if you don't feel like
making an extra account I can copy in the below remarks for you.
- Maciej
On Jun 2, 2011, at 8:54 PM, Darin Fisher wrote:
I'm concerned that implementing this will only encourage more use of
localStorage. The API
I think that these shortcomings are also strengths. A synchronous localStorage
is a drop-in replacement for cookies, which is a good thing to offer, and to
encourage. Practically, if it's only cookies vs. IndexedDB (or SQL Database),
I'd realistically choose the former for most code, and I'm
6 matches
Mail list logo
