Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
I asked whether LOADING should be 0 rather than 1. (There is no 0 constant
since we removed INITIAL.)
I also asked " is it possible to get the IDBRequest object from within the
openCursor/continue events without saving it off somewhere? If not, it
probably should be."
On Thu, Aug 26, 2010 at 2:46 AM, Jonas Sicking wrote:
> On Wed, Aug 25, 2010 at 3:42 PM, Jeremy Orlow wrote:
> > On Wed, Aug 25, 2010 at 9:29 PM, Jonas Sicking wrote:
> >>
> >> On Wed, Aug 25, 2010 at 8:12 AM, Jeremy Orlow
> wrote:
> >> > Also, the constants for the ready state should start with 0, not 1.
> >> > Also, what happens if someone does the following:
> >> > request = objectStore.openCursor();
> >> > request.onsuccess(function() {
> >> > event.result.continue();
> >> > request.abort();
> >> > event.result.continue();
> >> > }
> >> > Also, is it possible to get the IDBRequest object from within the
> >> > openCursor/continue events without saving it off somewhere? If not,
> it
> >> > probably should be.
> >>
> >> Didn't we decide to remove IDBRequest.abort()?
> >
> > Oh yeah...we did. :-)
> > Will file a bug.
> > What about the other questions?
>
> Yes, I think we should make it clear that readyState can go from DONE
> to LOADING.
>
> All other questions seemed related to abort()?
>
> / Jonas
>
[Bug 10453] New: [IndexedDB] IDBIndex.openObjectCursor should return an IDBRequest
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10453 Summary: [IndexedDB] IDBIndex.openObjectCursor should return an IDBRequest Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org IDBIndex.openObjectCursor should return an IDBRequest. There's no way it could synchronously return an IDBCursor. And based on the description below, it seems clear it was just a typo. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10328] change Accept-Charset to should not
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Anne 2010-08-26 12:13:10 --- Changed the specification as suggested. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10325] single conformance class
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Anne 2010-08-26 12:19:22 --- Fixed as suggested. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10322] open() should not throw for non same-origin URL
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Anne 2010-08-26 13:04:45 --- Please carefully review the new text. This was rather tricky. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10327] supported URL schemes in open()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Anne 2010-08-26 13:08:31 --- Fixed! (Also for redirects.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10324] send() should set Content-Type to text/html for HTML documents
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Anne 2010-08-26 13:19:01 --- Fixored. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: CfC: resolutions for XHR Bugs 103{22,24,25,27,28}; deadline August 25
On Wed, 11 Aug 2010 15:53:45 +0200, Arthur Barstow wrote: If you have any comments or concerns about any of the proposed resolutions, please send them to public-webapps by August 25 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. In the event there is consensus on a proposed resolution, Anne will update the latest Editor's Draft accordingly: http://dev.w3.org/2006/webapi/XMLHttpRequest/ This has now been done. (The CVS commits reference the bug reports.) We still need to resolve "user:password" in URLs somehow (maybe wait for the work from Adam Barth?) and I am still awaiting several clarifications in HTML5 that might result in a few mostly editorial changes. I'm still in the process of getting the W3C to host the test suite. Depending on how much longer that is going to take I might host it elsewhere meanwhile so we can at least start reviewing it. (Having made the most invasive changes to XMLHttpRequest Level 1 I will probably work on integrating asBlob/responseBlob in XMLHttpRequest Level 2 next.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Test Suite
On Wed, 11 Aug 2010 20:56:47 +0200, Anne van Kesteren wrote: [...] Hereby the promised update. For now the tests won't be hosted on w3.org. I am told that test.w3.org cannot and will not handle it as W3C sysadmin is afraid of the load PHP would put on it and an alternate solution is going to take a long time. So after discussing this with PLH I put them on tc.labs.opera.com: http://tc.labs.opera.com/apis/XMLHttpRequest/ You can get your own copy via Subversion: http://tc.labs.opera.com/svn/ When we want to move XMLHttpRequest to Proposed Recommendation status PLH should have figured something out to host the tests on w3.org. You can now run all the tests and see all the wonderful (euh, not) failures. Now in order to move XMLHttpRequest forward we need to: 1) Review the tests 2) Fix the browser bugs the tests reveal -- Anne van Kesteren http://annevankesteren.nl/
Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
On Thu, Aug 26, 2010 at 2:15 AM, Jeremy Orlow wrote:
> I asked whether LOADING should be 0 rather than 1. (There is no 0 constant
> since we removed INITIAL.)
I agree with this.
> I also asked " is it possible to get the IDBRequest object from within the
> openCursor/continue events without saving it off somewhere? If not, it
> probably should be."
I don't really feel strongly either way. I wouldn't be opposed to
adding a .request property to IDBCursor.
/ Jonas
> On Thu, Aug 26, 2010 at 2:46 AM, Jonas Sicking wrote:
>>
>> On Wed, Aug 25, 2010 at 3:42 PM, Jeremy Orlow wrote:
>> > On Wed, Aug 25, 2010 at 9:29 PM, Jonas Sicking wrote:
>> >>
>> >> On Wed, Aug 25, 2010 at 8:12 AM, Jeremy Orlow
>> >> wrote:
>> >> > Also, the constants for the ready state should start with 0, not 1.
>> >> > Also, what happens if someone does the following:
>> >> > request = objectStore.openCursor();
>> >> > request.onsuccess(function() {
>> >> > event.result.continue();
>> >> > request.abort();
>> >> > event.result.continue();
>> >> > }
>> >> > Also, is it possible to get the IDBRequest object from within the
>> >> > openCursor/continue events without saving it off somewhere? If not,
>> >> > it
>> >> > probably should be.
>> >>
>> >> Didn't we decide to remove IDBRequest.abort()?
>> >
>> > Oh yeah...we did. :-)
>> > Will file a bug.
>> > What about the other questions?
>>
>> Yes, I think we should make it clear that readyState can go from DONE
>> to LOADING.
>>
>> All other questions seemed related to abort()?
>>
>> / Jonas
>
>
Re: [IndexedDB] Constants and interfaces
On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow wrote: > On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking wrote: >> >> On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow >> wrote: >> > Last we spoke about constants in IndexedDB, (like >> > IDBKeyRange.LEFT_BOUND) I >> > believe we had decided that all the objects with constants would have an >> > interface object hanging off of window so it's possible to simply say >> > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when someone >> > tries >> > something like the following JS: |IDBCursor.continue()|? Given that >> > we're >> > using an interface object, I'd assume we throw some sort of exception or >> > something? I tried to figure out the answer in the WebIDL spec (I >> > imagine >> > it's somewhere around >> > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but >> > it's a >> > lot to wade through. Any advice would be great. >> >> I definitely think we should handle this the same way that all other >> interfaces does it. I.e. the same way that >> window.Node.appendChild(...) does it. In the Firefox implementation we >> just fall back to using our generic code for all this stuff, so >> nothing special goes on in the IndexedDB implementation. >> >> And yes, I think WebIDL should be the one defining what should happen. >> If it doesn't already someone should file a bug :) > > Ok, I figured out how interface objects are done in WebKit and got it > implemented. And everything looks like it's working fine except for > IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached > to it, but these aren't accessible from the interface object (and these > factories are the only possible way to get such an object). It makes sense > that methods are by default not considered static (i.e. must be called on an > instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. / Jonas
Using FileWriter.truncate() to extend the length of a file?
I noticed that FileWriter.truncate() can only be used to shorten a file, and
there does not seem to be a good way to grow a file using FileWriter without
appending data to it. By contrast, the POSIX ftruncate function can be used
to grow a file (zero padding it):
>From ftruncate(2):
"If the file previously was larger than this size, the extra data is lost.
If the file previously
was shorter, it is extended, and the extended part reads as null bytes
('\0')."
I think there are use cases for wanting to grow a file in advance of writing
data to it. For example, you might implement a system that downloads chunks
of a file in parallel using multiple XMLHttpRequest objects. The chunks may
arrive out-of-order.
A possible alternative API would be to support seeking beyond the end of the
file or writing to a starting offset that is beyond the length fo the file.
It may also be reasonable to support all of those in addition to truncating
to an offset greater than the length of the file.
Regards,
-Darin
