On May 4, 2010, at 7:17 PM, Pablo Castro wrote:
> The interaction between transactions and objects that allow multiple
> operations is giving us trouble. I need to elaborate a little to explain the
> problem.
>
> You can perform operations in IndexedDB with or without an explicitly started
>
On May 5, 2010, at 1:56 PM, Shawn Wilsher wrote:
> On 5/5/2010 1:09 PM, Jeremy Orlow wrote:
>> I'd also worry that if creating the transaction were completely transparent
>> to the user that they might not think to close it either. (I'm mainly
>> thinking about copy-and-paste coders here.)
> I s
Dumi,
I am not sure what the API expectations are for different levels of durability
of storage APIs. Is it:
1. Options passed to individual APIs selecting durability level
2. Separate API calls for different durability level
3. Allocations occurring through markup requiring user actions which a
On Wed, May 5, 2010 at 4:05 PM, Marcos Caceres wrote:
> On Wed, May 5, 2010 at 3:59 PM, Scott Wilson
> wrote:
>> On 5 May 2010, at 10:40, Robin Berjon wrote:
>>
>>> On May 4, 2010, at 19:29 , Scott Wilson wrote:
I've just been reading through the WARP spec again, and in particular this
On Thu, May 6, 2010 at 9:14 AM, Nikunj Mehta wrote:
>
> On May 4, 2010, at 7:17 PM, Pablo Castro wrote:
>
> > The interaction between transactions and objects that allow multiple
> operations is giving us trouble. I need to elaborate a little to explain the
> problem.
> >
> > You can perform oper
On Thu, May 6, 2010 at 9:36 AM, Nikunj Mehta wrote:
> Dumi,
>
> I am not sure what the API expectations are for different levels of
> durability of storage APIs. Is it:
>
> 1. Options passed to individual APIs selecting durability level
> 2. Separate API calls for different durability level
> 3.
Andreas
Thanks, good catch.
regards, Frederick
Frederick Hirsch
Nokia
On May 5, 2010, at 11:41 AM, ext Andreas Kuehne wrote:
Hi all,
just a minor comment found by build a test case :
Section 7.1. Common Constraints for Signature Generation and
Validation
1. [...]
2.
in the proposed editors draft [1] this is section 10.2 item #3
I suggest we change 3a from "The URI attribute ..." to be "For
references that are not same-document references, the URI attribute..."
regards, Frederick
Frederick Hirsch
Nokia
On May 5, 2010, at 11:41 AM, ext Andreas Kuehne
On Thu, May 6, 2010 at 3:02 PM, Frederick Hirsch
wrote:
> in the proposed editors draft [1] this is section 10.2 item #3
>
> I suggest we change 3a from "The URI attribute ..." to be "For references
> that are not same-document references, the URI attribute..."
Done! thanks!
--
Marcos Caceres
O
The draft minutes from the May 6 Widgets voice conference are
available at the following and copied below:
http://www.w3.org/2010/05/06-wam-minutes.html
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before May 13 (the next Widgets
Lachlan Hunt wrote:
> I believe the test suite is nearly ready [1].
>
> As I mentioned last year, Minefield currently passes 100% of the test
> suite. However, this has not yet shipped in a release build. I assume it
> will make it into the next major release after the current 3.6.x branch.
>
On 5/6/10 10:44 AM, Stewart Brodie wrote:
Taking the null, explicit undefined and implicit undefined test cases
together, I don't think I've got any two browsers here that behave the same
way. :-/
Yes, that's why we can't exit CR. ;)
Note that part of the issue here is that the spec flip-flop
Hi folks,
We've been playing around with the async API and have made some
changes to the IDBRequest interface that we'd like feedback on and
hopefully inclusion in the spec. Here's what we have now:
interface IDBRequest : EventTarget {
void abort();
const unsigned short INITIAL = 0;
Hey folks,
I'm working with Shawn on the Firefox implementation. Here's our idea
as of now, would you all please comment about things you like or
dislike? Hopefully this follows the gist of the comments shared
already.
interface IndexedDatabaseRequest {
IDBRequest open(in DOMString name,
Hey folks,
I'm working with Shawn on the Firefox implementation. Here's our idea
as of now, would you all please comment about things you like or
dislike? Hopefully this follows the gist of the comments shared
already.
interface IndexedDatabaseRequest {
IDBRequest open(in DOMString name,
nikunj, i agree with what jeremy said. i think we need each storage API to
be able to specify what kind of storage it needs (and i'm trying to add an
optional flag for that to WebSQLDatabases, which is your option #1). in
addition to that, i think we need an API that would allow an app to request
p
Here is a brief proposal for how we could simplify the current set of CORS
headers. We can use this thread to evaluate whether it is worth breaking
with what Firefox, Safari, Chrome, and IE are doing now. And whether all
parties are willing to change their supported syntax in due course.
Fu
XML is also a misnomer. And HTTP is confusing since it also works over
https.
At least we agree on Request.
On Apr 21, 2010 12:24 PM, "Maciej Stachowiak" wrote:
On Apr 21, 2010, at 8:57 AM, Anne van Kesteren wrote:
> On Wed, 21 Apr 2010 23:37:54 +0900, Mark S...
I agree that "Anonymous" or "A
On Fri, 09 Apr 2010 09:51:16 +0900, Maciej Stachowiak
wrote:
On Apr 8, 2010, at 5:20 PM, Tyler Close wrote:
This unique origin would still need to discard Set-Cookie response
headers to prevent the accumulation of credentials associated with the
unique origin. It would also need to prohibit th
On Fri, 7 May 2010, Anne van Kesteren wrote:
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9603
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9604
>
> I expect Ian to address these to our satisfaction or provide an
> alternative solution that does.
These seem uncontroversial; I'll get t
20 matches
Mail list logo
