BITSY is offered as a complementary technique for WebStorage not as a
replacement to SQL.
On Apr 24, 2009, at 4:03 PM, Ian Hickson wrote:
On Fri, 24 Apr 2009, Nikunj Mehta wrote:
We want to standardize interception of HTTP requests inside Web
browsers
so as to allow applications to do th
On Apr 17, 2009, at 2:39 PM, Jonas Sicking wrote:
On Tue, Apr 14, 2009 at 9:08 AM, Nikunj Mehta
wrote:
On Apr 11, 2009, at 12:39 AM, Jonas Sicking wrote:
On Fri, Apr 10, 2009 at 10:55 PM, Nikunj Mehta >
wrote:
On Apr 10, 2009, at 3:13 PM, Ian Hickson wrote:
On Fri, 10 Apr 2009, Nikunj
On Fri, 24 Apr 2009, Nikunj Mehta wrote:
>
> We want to standardize interception of HTTP requests inside Web browsers
> so as to allow applications to do their own interception and seamlessly
> access data on-line and off-line. This is primarily targeted at
> improving availability of data used
Forwarded from whatwg upon Ian's request.
Forwarded conversation
Subject: Exposing EventTarget to JavaScript
From: *Erik Arvidsson*
Date: Fri, Apr 24, 2009 at 10:00
To: whatwg
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events f
Hi, Alex-
Alex Russell wrote (on 4/24/09 5:31 PM):
The DOM function "addEventListener" is probably too long. It should,
instead, be named something much shorter owing to the amount of
exercise it receives. Further, it should default the last parameter to
be "false" (non-capture-phase). This cal
The storage event currently seems to be dispatched synchronously. Together
with the storage mutex this easily creates a deadlock:
Window A (origin x):
localStorage.x = "foo"
Window B (origin x):
onstorage = function(e) { print(localStorage.x) }
We think it should be dispatched async
We noticed a problem while working on Web Storage. The broadcasting
feature allows fork bombing. I personally couldn't think of any other
features that allows such a thing.
Works against Gecko:
http://dump.testsuite.org/2009/storage/demo-001.htm
Works against WebKit:
http://dump.testsu
>From this thread on whatwg:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019379.html
and per Hixie's request that I re-direct this particular discussion here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019381.html
The DOM function "addEventListener
In our system when a widget is instantiated we generate our own
instance hashes which we append to the widget URL as a parameter, and
our Storage implementation uses this parameter when it needs to make a
request back to our prefs web service to load preferences, or to set a
preference.
I
Dear Arve,
Here are my comments on your Widgets A&E last editor's draft.
1. Change "A environment in which a Widget interface is presented to the user."
to "An environment in which a Widget interface is presented to the user."
2. All URLs in the "Step 8" hyperlinks in section "The Widget Interf
I agree.
- No exception to maintain coherence.
- Name "changeMode()".
Arve> It should be noted, however, that this is problematic on device for a
number of reasons,
> given that floating or mini widgets would typically exist on some "desktop"
> or in an application
> grid, so these mode changes
There's quite a big interoperability problem with the events.
* Per the specification the event is to be dispatched on Window (and does
not bubble).
* In Firefox it is dispatched on body and then bubbles up to Window.
* In WebKit it is dispatched on body (and does not bubble).
* In Interne
how about this:
Note that with an optional algorithm interoperability may not always
be possible if user agents have not implemented it. Implementation of
this algorithm is encouraged since it can become mandatory in a
subsequent release of this specification, and this may become
necess
On Fri, Apr 24, 2009 at 1:25 PM, Arve Bersvendsen wrote:
> On Fri, 24 Apr 2009 13:21:15 +0200, Marcos Caceres wrote:
>
>>> In that case, it is not a request, so widget.changeMode()
>>> would be more appropriate, where a user agent MAY choose to not honor
>>> the request.
>>>
>>
>> If it doesn't,
On 24 Apr 2009, at 13:19, Marcos Caceres wrote:
We need to figure out what the baseline policy is for access to
persistent
storage that is shared across several instances, or even several
widgets.
Agreed. We are unsure if that goes into our spec or into the
WebStorage spec.
I suspect th
On Fri, 24 Apr 2009 13:21:15 +0200, Marcos Caceres wrote:
>> In that case, it is not a request, so widget.changeMode()
>> would be more appropriate, where a user agent MAY choose to not honor
>> the request.
>>
>
> If it doesn't, it would throw an exception. Right?
I would much prefer that i
On Fri, Apr 24, 2009 at 12:36 PM, Arve Bersvendsen wrote:
> On Fri, 24 Apr 2009 12:26:29 +0200, wrote:
>
>> Hello guys.
>>
>> What would you think of an API for empowering the Widget to "ask for
>> mode change"?
>> Something like:
>> widget.ModeChangeRequest();
>>
>> Of course the WUA can i
On Fri, Apr 24, 2009 at 11:51 AM, Thomas Roessler wrote:
> On 24 Apr 2009, at 10:54, Marcos Caceres wrote:
>
>> It would be really helpful if you could enumerate these complexities,
>> please?
>
> What I'm proposing currently (and I think other proposals are having the
> same effect) implies that
On Fri, 24 Apr 2009 12:26:29 +0200, wrote:
> Hello guys.
>
> What would you think of an API for empowering the Widget to "ask for
> mode change"?
> Something like:
> widget.ModeChangeRequest();
>
> Of course the WUA can ignore the request.
In that case, it is not a request, so widget.cha
On 24 Apr 2009, at 10:54, Marcos Caceres wrote:
It would be really helpful if you could enumerate these
complexities, please?
What I'm proposing currently (and I think other proposals are having
the same effect) implies that there is a new and separate origin every
time a widget is newly
On Fri, 24 Apr 2009 08:32:31 +0200, Nikunj Mehta
wrote:
On Apr 23, 2009, at 1:47 PM, Anne van Kesteren wrote:
FWIW, Opera is primarily interested in implementing the APIs currently
in the specification (including the SQL API). Specifying the specifics
of the SQL dialect in due course would
"I would like to see some text cautioning authors not to rely on this
algorithm, since it is optional in user agents."
Agreed - in fact I think a general statement about use of optional algorithms
would be beneficial
-Original Message-
From: public-webapps-requ...@w3.org [mailto:publ
On Apr 24, 2009, at 11:12 , Marcos Caceres wrote:
Also note that a scheme doesn't necessarily uniquely map to a
protocol, so
it should probably say "scheme handler".
Right. I thought the same thing. I used "protocol handler" to be
consistent with HTML5.
Ah, well before we use different term
On Thu, Apr 23, 2009 at 2:26 PM, Robin Berjon wrote:
> On Apr 23, 2009, at 12:36 , Marcos Caceres wrote:
>>>
>>> 3. [User Agents] "A user agent is an implementation" a bit vague. Perhaps
>>> some of the text in the following note should be move here, to refine the
>>> definition.
>>
>> I changed i
Hi Thomas,
On Fri, Apr 24, 2009 at 10:48 AM, Thomas Roessler wrote:
> The implication is twofold:
>
> 1. If widgets are to use one of these storage mechanisms, then we need to
> say what (instead of origin) the storage is scoped by, and how a widget
> acquires an instance.
This is true.
> 2. As
The implication is twofold:
1. If widgets are to use one of these storage mechanisms, then we need
to say what (instead of origin) the storage is scoped by, and how a
widget acquires an instance.
2. As far as security policies are concerned, this suggests that we
are acquiring an addition
Hi Frederick,
Thanks for updating the spec! comment below.
On Fri, Apr 24, 2009 at 3:14 AM, Frederick Hirsch
wrote:
> I have updated the Widget Signature draft to reflect decisions on today's
> call, as follows:
>
> Added ECDSAwithSHA256 as SHOULD signature algorithm
I would like to see some te
On Thu, 23 Apr 2009 20:17:07 +0200, Thomas Roessler wrote:
> Guido Grassel is reminding me that the HTML5 storage API keys off
> origin. Thy means another wrinkle or the uri scheme/origin discussion.
Note that only the instantiations of storage, through the localStorage and
sessionStorage, ar
28 matches
Mail list logo
