Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching isFile
/ isDirectory information in memory would be ok if user could get an
informative error code when an entry becomes stale -- and seems like that's
the case. So I'm almost convinced :)
One
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9745
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro pablo.cas...@microsoft.comwrote:
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
Orlow
Sent: Thursday, August 12, 2010 2:18 AM
I think we should first break down the use cases and look at how many of
them just need _a_
On Fri, 2010-08-13 at 00:03 +0200, Anne van Kesteren wrote:
On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras joao.ei...@gmail.com wrote:
b)
Could there be a way to opt-in into not following redirection chains ?
For instance, a redirectCount property, default value would be
something
On 13.08.2010 00:03, Anne van Kesteren wrote:
...
For instance, a redirectCount property, default value would be
something like Infinity (the user agent could then cap the maximum
amount of redirects), and setting it to 0 would prevent any redirect,
and setting to something greater than 0 would
Julian Reschke wrote:
On 13.08.2010 00:03, Anne van Kesteren wrote:
...
For instance, a redirectCount property, default value would be
something like Infinity (the user agent could then cap the maximum
amount of redirects), and setting it to 0 would prevent any redirect,
and setting to
This is a Call for Consensus to remove the openURL method from the
Widget object as captured in Issue-116 and Action-568 and discussed on
the mail list ([1], [2], [3]) and during several calls (most recently
[4], [5]):
* Issue-116 Need to flesh out the security considerations for the
openURL
On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro pablo.cas...@microsoft.com
wrote:
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
Orlow
Sent: Thursday, August 12, 2010 2:18 AM
I think we should
On Fri, Aug 13, 2010 at 5:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro
pablo.cas...@microsoft.com
wrote:
From: jor...@google.com [mailto:jor...@google.com] On Behalf
On Fri, Aug 13, 2010 at 10:58 AM, Eric Uhrhane er...@google.com wrote:
On Thu, Aug 12, 2010 at 11:08 PM, Kinuko Yasuda kin...@chromium.org
wrote:
Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching
isFile
/ isDirectory information in
In the context of transactions, readers using READ_ONLY and writers using
READ_WRITE may block each other when starting transactions, at least for cases
where the underlying implementation uses locking for isolation. Since we allow
multiple readers and they can start while other readers were
Fixed.
While I was in there, I deleted an unused class [FileSystemsCallback]
and changed the boolean persistent parameter [from requestFileSystem
and requestFileSystemSync] to be a more-general flag, to allow for
future expansion.
Eric
On Fri, Aug 13, 2010 at 11:23 AM, Kinuko Yasuda
Comments:
Should we have a more explicit way to specify and notify users that some
updates may require data conversion and
user data will be converted after the widget is updated? Due to the
error-prone nature of such conversion, users
may want to back up their data before proceeding with an
13 matches
Mail list logo
