On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:
Some quick notes/questions...
- I think the manifest should be some structured, extensible format
such as XML or JSON. The current text-based format is going to
On Wed, Aug 20, 2008 at 5:36 PM, Ian Hickson [EMAIL PROTECTED] wrote:
I've received feedback from a number of people requesting a rethink to the
API for creating and communicating with workers.
Here is a skeleton of a new proposal. It makes the following changes:
* Shared workers and
Hello all, I have many comments on the Offline Web Applications corner of
the HTML5 spec. This is the first round of comments you'll see coming from
me. This one is mostly top-level comments.
5.7.2 Application caches
I found the terminology used to describe the contents of the cache sometimes
as a fallback for network or server(5xx)
errors
- do not purge the resource upon expiration
Comments?
On Mon, Aug 25, 2008 at 11:54 AM, Michael Nordman [EMAIL PROTECTED]wrote:
Hello all, I have many comments on the Offline Web Applications corner of
the HTML5 spec. This is the first round
Hi Dave,
Thanx for taking a look.
On Mon, Sep 15, 2008 at 2:25 PM, Dave Camp [EMAIL PROTECTED] wrote:
On Mon, Aug 25, 2008 at 11:54 AM, Michael Nordman [EMAIL PROTECTED]
wrote:
Manifest file section headers:
* BYPASS: list of url [namespaces/filters]
* CACHE: list of exact [urls
A fallback entry is paired with a url namespace. The fallback resource is
cached at manifest update time. If a request that matches the namespace
results in a server or network error, the fallback resource is returned in
its place. In the current draft of the spec, this is mired together with
be provided in
such a way that this awkwardness could be avoided.
Some ideas...
bool contains(url);
string[] getItems();
Regards,
Maciej
On Tue, Oct 7, 2008 at 2:03 PM, Michael Nordman [EMAIL PROTECTED] wrote:
Some more comments for the whatwg bit bucket...
1) Foreign entry detection
Here's the thing i'm trying to avoid in section 5.7.6 where it
discusses the add(url) method.
...
8. Wait for there to be no running scripts, or at least no running
scripts that can reach an ApplicationCache object associated with the
application cache with which this ApplicationCache object
I haven't reviewed the new draft yet just a preliminary comment for now.
* intercept namespaces [new]
This form of namespace is not in the spec at present. This is a proposal to
add it. It is a heavily used feature of the Gears LocalServer. The basic
idea is to intercept requests into this
On Fri, Nov 14, 2008 at 4:37 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Fri, Nov 14, 2008 at 4:33 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Hmm.. this makes a lot of sense for importScripts, but for XHR you
probably
want the baseURI to be that of the opening page, since it's quite
On Mon, Nov 17, 2008 at 8:05 PM, Ian Hickson [EMAIL PROTECTED] wrote:
Based on this and other offline feedback (no pun intended), I've changed
the spec to make iframes never inherit the manifest.
Seems workable... of course until app developers actually start trying to
use this system, the
On Fri, Oct 17, 2008 at 5:36 PM, Ian Hickson [EMAIL PROTECTED] wrote:
- I know you added the behavior of failing loads when a URL is not in
the manifest based on something I said, but now that I read it, it feels
a bit draconian. I wish that developers could somehow easily control the
On Thu, Jan 22, 2009 at 4:34 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 18 Nov 2008, Michael Nordman wrote:
Fwi, this piece of functionality may warrant some actual consideration.
I think this would add very little complexity to the spec and
implementations, but would add a great deal
Just need a clarification...
* If the flag document-is-markup is true, and document was loaded from
an application cache, and there is no manifest URL
* If the flag document-is-markup is true, If document was loaded from
an application cache, and the URL of the manifest of that cache's
Note that the document-is-markup flag will likely go away, and be
replaced by just checking to see if there is a manifest (as it was
before).
The reason this particular thing might change is that I checked it in
yesterday and this morning one of the Apple guys complained to me on IRC
One key feature that IMHO is needed in this area is sharing of events between
pages/windows
A cross-page event broadcast facility is co-mingled with the
DOMStorage corner of the spec (see 5.11.1.5 The storage event).
It may be nice to carve that out as a separate facility that can be
utilized
On Mon, Mar 2, 2009 at 4:48 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 03 Mar 2009 05:49:12 +0900, Michael Nordman micha...@google.com
wrote:
A cross-page event broadcast facility is co-mingled with the
DOMStorage corner of the spec (see 5.11.1.5 The storage event).
It may
Allowing cookie to be set would unfortunately create a synchronous
communication channel between the worker and the main window. This is
something that we need to avoid to prevent users from having to deal
with locking and other thread related issues.
Hmmm... the cookie setting API could be
On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman micha...@google.com wrote:
Allowing cookie to be set would unfortunately create a synchronous
communication channel between the worker and the main window. This is
something that we need to avoid to prevent users from having to deal
with locking
On Thu, Mar 5, 2009 at 5:40 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 06 Mar 2009 10:35:19 +0900, Jonas Sicking jo...@sicking.cc wrote:
Gecko, and I believe the latest XHR spec drafts, have disabled access
to cookies through XHR in order to prevent leaking of HTTPOnly
cookies.
Jonas (and I) were talking about setRequestHeader(),
getAllResponseHeaders(), and getResponseHeader().
Sure.
postMessage()? :-)
That certainly works for dedicated workers. Not so great for shared
workers or persistent workers. In the shared case, the postMessage
sender and receiver would
Anyhow, I'm not averse to having an asynchronous API, but I'd still like to
enable workers to do this:
setCookie(cookiestring)
xhr.send();
Forcing workers to do all of their cookie-laden network requests via a
double-callback (set cookie, wait for callback, invoke xhr, wait for
response)
+1 UTF-8 always simplification
On Thu, Mar 19, 2009 at 3:43 PM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 19 Mar 2009 23:39:43 +0100, Dmitry Titov dim...@chromium.org
wrote:
FYI: per IRC talk, the answer is the scripts should be using UTF-8 in
the absence of explicit override. Spec
On Fri, Mar 20, 2009 at 1:47 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Mar 20, 2009 at 1:23 PM, Jeremy Orlow jor...@google.com wrote:
What is the need for localStorage access within workers? Technically if
someone really needed to access it, they could always have a function in the
On Fri, Mar 20, 2009 at 3:34 PM, Dmitry Titov dim...@google.com wrote:
On Fri, Mar 20, 2009 at 2:39 PM, Drew Wilson atwil...@google.com wrote:
One alternative I'd like to propose is to remove access to localStorage
for dedicated workers, and give SharedWorkers access to localStorage, but
have
On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman a...@google.com wrote:
On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking jo...@sicking.cc wrote:
The problem with synchronously grabbing the lock is that we can only
ever have one feature that uses synchronous locks, otherwise we'll
risk
workers, or else just enforce a max time that a
worker can hold the lock.
-atw
On Sun, Mar 22, 2009 at 10:46 AM, Michael Nordman micha...@google.comwrote:
On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman a...@google.com wrote:
On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking jo
On Sun, Mar 22, 2009 at 11:53 AM, Aaron Boodman a...@google.com wrote:
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson atwil...@google.com wrote:
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to
On Sun, Mar 22, 2009 at 12:07 PM, Michael Nordman micha...@google.comwrote:
I don't see how denying workers solves the problem. In a multi-threaded
browser, this has to be resolved reasonably even in the absence of workers.
There hasn't been much discussion of this yet... a few comments on the list
between august and november of 2008...
[michaeln] How do workers and appCaches interact?
[ian] workers are associated with browsing contexts, so they go through
the
normal app cache networking changes. This
, and might also be applicable to normal shared
workers.
-atw
2009/3/25 Michael Nordman micha...@google.com
There hasn't been much discussion of this yet... a few comments on the list
between august and november of 2008...
[michaeln] How do workers and appCaches interact?
[ian
. This is a problem with the current API for localStorage in windows
as well.
I've made the spec explicitly have a single shared lock for all features
that need locking (currently just .cookie and .localStorage).
On Sun, 22 Mar 2009, Michael Nordman wrote:
Given an async api, would
sessionLifetime + tabSpecificScope doesn't make much sense since
you get a new set of tabs when starting a new session
Sorry... make that persistentLifetime + tabScope doesn't make sense.
On Fri, Mar 27, 2009 at 3:29 PM, Michael Nordman micha...@google.comwrote:
On Tue, Mar 24, 2009
I think it makes sense to treat dedicated workers as simple subresources,
not separate browsing contexts, and that they should thus just use the
application cache of their parent browsing contexts. This is what WebKit
does, according to ap.
I've now done this in the spec.
Sounds good.
I'd like to propose a way forward. Please have an open mind.
The objections your hearing from the chrome world are around the locking
semantics being proposed. In various discussions the terms evil,
troubling, and onerous have been used to describe what we think about
aspects of those semantics.
There are additional constraints that haven't been mentioned yet...
Plugins.
The current model for plugins is that they execute in a single-threaded
world. Chrome maintains that model by hosting each plugin in its own process
and RPC'ing method invocations back and forth between calling pages and
On Mon, Apr 6, 2009 at 7:17 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Apr 7, 2009 at 5:04 AM, Michael Nordman micha...@google.comwrote:
There are additional constraints that haven't been mentioned yet...
Plugins.
The current model for plugins is that they execute in a single
On Mon, Apr 6, 2009 at 7:28 PM, Michael Nordman micha...@google.com wrote:
On Mon, Apr 6, 2009 at 7:17 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Apr 7, 2009 at 5:04 AM, Michael Nordman micha...@google.comwrote:
There are additional constraints that haven't been mentioned yet
I think a user agent has to harmonize across all manner of shared
resources being introduced to ensure a reasonable behavior is
provided.
* localstorage (and the breadth of the associated events)
* databases
* appcaches
* named shared workers
Starting with nothing, keeping it all walled-off from
On Tue, Apr 7, 2009 at 6:30 PM, Brady Eidson beid...@apple.com wrote:
On Apr 7, 2009, at 6:19 PM, Ian Fette (イアンフェッティ) wrote:
Yeah, but my argument is more that Incognito / Private / whatever is like
starting from a boot cdrom with a filesystem that's in memory.
This is actually not
For what it's worth, this was my immediate thought as well upon
reading the idea. The database is insufficiently fast on some
platforms to server as an IPC mechanism and there are practical
limitations with having too many contending transactions so my
instinct would be to build large
Would there be a lot of overhead in just doing this through XMLHttpRequest,
some processing, and the database API?
Good question. I think you're suggesting...
* statementsToCreateAndPopulateSQLDatabase = httpGet();
* foreach(statement in above) { execute(statement); }
* now you get to run
What appcache (if any) should the resulting iframes be associated with? I
think per the spec, the answer is none. Is that the correct answer?
html manifest='myManifestFile'
body
script language=JavaScript
function frameContents1()
{
var doc = frame1.document;
doc.open();
of what? The code executes in the global context, doesn’t it?
Chris
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Michael Nordman
Sent: Friday, June 05, 2009 2:45 AM
To: WHATWG List
Subject: [whatwg] AppCache
On Tue, Jun 9, 2009 at 12:48 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 09 Jun 2009 03:33:56 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 11 May 2009, Samuel Santos wrote:
I was asked by a client if it was possible to implement something
similar to the asynchronous file
This is the solution that Firefox 3.5 uses. We use a pool of
relatively few OS threads (5 or so iirc). This pool is then scheduled
to run worker tasks as they are scheduled. So for example if you
create 1000 worker objects, those 5 threads will take turns to execute
the initial scripts one
On Wed, Jun 10, 2009 at 1:46 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordmanmicha...@google.com
wrote:
This is the solution that Firefox 3.5 uses. We use a pool of
relatively few OS threads (5 or so iirc). This pool is then scheduled
to run
This breakdown is a useful way to think about application state in the
browser. Another axis that could be incorporated into the model is lifetime.
There is some overlap between Server-Controlled and Script-Controlled realms
in cookies, applications definitely have a dependency on that overlap
Does disconnect() attempt to flush pending messages or drop them?
There isn't a way to determine if the WebSocket is successfully sending the
postMessage data? For all the caller knows, its just backing up and not
going anywhere.
Something that might add value is an onmessagesent event that fires
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote:
Forcing applications to build their own send/ack functionality would be
pretty tragic considering that WebSockets are built on top of TCP.
-
On Fri, Jun 26, 2009 at 3:33 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman micha...@google.comwrote:
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam
On Fri, Jun 26, 2009 at 4:34 PM, Jeff Walden
jwalden+wha...@mit.edujwalden%2bwha...@mit.edu
wrote:
On 26.6.09 13:52, Michael Nordman wrote:
There isn't a way to determine if the WebSocket is successfully sending
the postMessage data? For all the caller knows, its just backing up
On Sat, Jun 27, 2009 at 3:18 PM, Jeff Walden
jwalden+wha...@mit.edujwalden%2bwha...@mit.edu
wrote:
On 26.6.09 16:49, Michael Nordman wrote:
Progress bars are routinely implemented without get hi-level application
acks from the other side. XMLHttpRequest.upload.onprogress is one such
example
On Tue, Jun 30, 2009 at 9:29 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 4 Jun 2009, Michael Nordman wrote:
What appcache (if any) should the resulting iframes be associated with? I
think per the spec, the answer is none. Is that the correct answer?
html manifest='myManifestFile
Yup... the source of grief is...
6.9.7 Changes to the networking model5: Fail the resource load.
The intent behind this was making the testing of offline application
easier. Given the unintended consequence Aaron brought up, we should
probably revisit this.
Maybe only fail to load the
Couple of comments...
1) Aaron's comment was not about caching them at all, it was about referring
to them from a cached application and having them load via the network as
usual. Step 5 gets in the way of that.
2) The spec already allows for cross-origin caching, they can be explicitly
listed
On Mon, Jul 6, 2009 at 2:40 PM, Aaron Boodman a...@google.com wrote:
On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sickingjo...@sicking.cc wrote:
On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyteawh...@google.com wrote:
When a page is loaded from an AppCache, even when online, external
resources
such
renamed disconnect() to close() in both EventSource and WebSocket.
On Fri, 26 Jun 2009, Michael Nordman wrote:
Does disconnect() attempt to flush pending messages or drop them? There
isn't a way to determine if the WebSocket is successfully sending the
postMessage data? For all the caller
This type of UA-specific setting is something best left outside the spec
entirely.
Yup
On Wed, Jul 8, 2009 at 10:08 AM, Drew Wilson atwil...@google.com wrote:
I think Ian's decision to add no language to the spec is the correct one.
To be clear, we were never asking for Ian to put a limit in
On Sun, Jul 19, 2009 at 3:10 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 1 Jul 2009, Michael Nordman wrote:
On Tue, Jun 30, 2009 at 9:29 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 4 Jun 2009, Michael Nordman wrote:
What appcache (if any) should the resulting iframes be associated
There is a proposal in the w3c world that attempts to address this use
case...http://dev.w3.org/2006/webapi/DataCache/
There seems to be a growing consensus (on the public-webapps list) that the
feature set described in that proposal should be folded in as an extension
to the appcache. The draft
Obviously we need more web platform capabilities to make such use cases a
reality, but they are foreseeable and we should deal with them in some
reasonable way.
Couldn't agree more.
The proposed websocket interface is too dumbed down. The caller doesn't know
what the impl is doing, and the impl
On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiakm...@apple.com wrote:
On Jul 27, 2009, at 10:51 PM, David Levin wrote:
It sounds like most of the concerns are about the 2nd part of this
proposal:
allowing a
, Michael Nordman wrote:
The proposed websocket interface is too dumbed down. The caller doesn't
know what the impl is doing, and the impl doesn't know what the caller
is trying to do. As a consequence, there is no reasonable action that
either can take when buffers start overflowing. Typically
'Named' cache groups under a single manifest url is an interesting idea.
Presumably the webapp would be generating the 'name' in the manifest file
based on a cookie value.
Another possibility is something along the lines of what is proposed in the
DataCache draft: the manifest indicates a cookie
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson m...@google.com wrote:
On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr.jackalm...@gmail.com
wrote:
On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidsonm...@google.com
So use an out-of-band extension mechanism to establish trust and
permissioning for capabilities that fall out of bounds of the 'regular' web
model.
So lets put that to practice on this particular two-part proposal...
Our proposed solution has two parts.
This first part (below) falls within the
Hello,
How empty html manifest= attribute values are handled in the
section 9.2.5.5 may want some massaging.
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#parser-appcache
If the Document is being loaded as part of navigation of a browsing context,
then: if the newly
On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilsonmike...@hotmail.com wrote:
Drew Wilson wrote:
SharedWorkers are overloaded to provide a way for
pages under the same domain to share state, but
this seems like an orthogonal goal to parallel
execution and I suspect that we may have ended
up with a
On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilsonmike...@hotmail.com wrote:
Michael Nordman wrote:
On Mon, Aug 3, 2009 at 3:05 AM, Mike
Wilsonmike...@hotmail.com wrote:
Assuming this shared state doesn't require a full
JavaScript global context, and could do with some
root object
On Tue, Aug 4, 2009 at 1:08 AM, Mike Wilson mike...@hotmail.com wrote:
Michael Nordman wrote:
On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote:
Btw, another reflection is that this mail thread is about
introducing a client/server model in the browser. Some
mentions of complex code
Tim Berners-Lee seems to think this could be a valid use of URI references.
http://www.w3.org/DesignIssues/Fragment.htmlThe significance of the
fragment identifier is a function of the MIME type of the object
Are there any existing semantics defined for fragments on text/java-script
objects?
//
What purpose the the 'name' serve? Just seems uncessary to have the notion
of 'named' workers. They need to be identified. The url, including the
fragment part, could serve that purpse just fine without a seperate 'name'.
The 'name' is not enough to identify the worker, url,name is the
identifier.
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
This is an interesting suggestion as it isolates the
stateful parts from the rest of the previous suggestions.
I like state.
Here's how I see how it fits inside the big picture:
Scope Serialized state
On Wed, Aug 19, 2009 at 10:48 AM, Dmitry Titov dim...@google.com wrote:
On Wed, Aug 19, 2009 at 7:37 AM, Patrick Mueller
pmue...@muellerware.orgwrote:
var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as
experimental feature?
context.onload = function () {...}
On Tue, Aug 18, 2009 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 18, 2009 at 7:53 PM, Drew Wilsonatwil...@google.com wrote:
An alternative would be to make the name parameter optional, where
omitting the name would create an unnamed worker that is
identified/shared
only
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller pmue...@muellerware.orgwrote:
Dmitry Titov wrote:
The return value from a constructor is the Global Script's global scope
object. It can be used to directly access functions and variables defined
in global scope of the Global Script. While
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
Dmitry had a later note which combined creation of the context and loading
of the script. But I suspect one thing people will want to do, in
development anyway, is load multiple scripts into a context - like you can
in workers. Which would mean we'd still need a function to load a script,
after the first script is loaded/executed, to deal with
dependencies between scripts). The alternative is to force applications to
do their own manual ordering.
-atw
On Mon, Aug 24, 2009 at 11:32 AM, Michael Nordman micha...@google.comwrote:
Dmitry had a later note which combined creation
The statement in section 4.3 doesn't appear to specify any behavior... its
just an informational statement.
The statement in section 6.1 suggests to prohibit the development of a UI
that mentions local storage as a distinct repository seperate from cookies.
This doesn't belong in the spec imho.
At a minimum the HTML 5 spec should be silent on how user agents implement
local storage policies.
+1 linus
The sort of 'policies' being discussed are feeling 'out-of-scope' for the
HTML5 spec. The practical realities are that eviction needs to be there in
some form w/o an explicit user
wrote:
On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman micha...@google.comwrote:
A mandate from on high that says 'shall store forever and ever' will be
promptly ignored because its impossible to make that guarantee.
That's not the proposed mandate. The proposed mandate is thou shalt
Maybe the local storage API needs a way to distinguish between cached data
that can be silently thrown away, and important data that can't.*
*
*What if instead of the storage APIs providing a way to distinguish things,
UA's provide a way for users to indicate which applications are important,
and
On Wed, Aug 26, 2009 at 5:08 PM, Remco remc...@gmail.com wrote:
On Thu, Aug 27, 2009 at 1:55 AM, Michael Nordmanmicha...@google.com
wrote:
Ok... I overstated things ;)
What seems inevitable are vista-like prompts to allow something (or prods
to
delete something) seemingly unrelated to a
just described a way to 'bless' things.
On Wed, Aug 26, 2009 at 5:06 PM, Jens Alfke s...@google.com wrote:
On Aug 26, 2009, at 4:55 PM, Michael Nordman wrote:
What seems inevitable are vista-like prompts to allow something (or prods
to delete something) seemingly unrelated to a user's
On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote:
I started writing a detailed rebuttal to Linus's reply, but by the time I
was finished, many others had already delivered more targetted replies.
So I'll cut the rebuttal format and make a few specific points.
- Many
And to confound the problem further, UAs dont have meta-data on hand with
which to relate various pieces of local data together and attribute them to
a specific user-identifiable 'application'. Everything is bound to a
security-origin, but that doesn't clearly identify or label an
'application'.
2009/8/27 Jonas Sicking jo...@sicking.cc
2009/8/27 Ian Fette (イアンフェッティ) ife...@google.com:
I would much rather have a well thought-out local filesystem proposal,
than
continued creep of the existing File and Local Storage proposal. These
proposals are both designed from the perspective of
On Fri, Aug 28, 2009 at 11:12 AM, Jens Alfke s...@google.com wrote:
On Aug 28, 2009, at 10:51 AM, Brady Eidson wrote:
I would *NOT* be on board with the spec requiring anything about where the
file goes on the filesystem. I have never been convinced by the argument
that users always need
'Commit' implies that it hasn't been committed yet, which is not true. This
will be misleading to those developers that do understand the locking
semantics (and transactional semantics) and are looking to defeat them. With
the 'commit' naming, we'd be doing a diservice to exactly the sort of
These arguments against the proposal are not persuasive. I remain of the
opinion that the GlobalScript proposal has merit.
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Aug 2009, Dmitry Titov wrote:
Currently there is no mechanism to directly share DOM, code
This would be a nice addition... seems like an event plus a read-only
property on the 'window' object could work.
window.idleState;
window.onidlestatechange = function(e) {...}
On Fri, Aug 28, 2009 at 3:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 28, 2009 at 2:47 PM, David
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers to
use the more difficult database api for all storage needs, and to roll their
own change event mechanisms (based on postMessage). Thats a bunch of busy
work if a name/value pair
I'm happy to see this getting sorted out. I like maciej's idea too.- Keep
the current LocalStorage API, but make it give no concurrency guarantees
whatsoever. (IE's impl i think)
- Add a simple optional transactional model for aware authors who want
better consistency guarantees.
There is one
+1, a nice refactoring of the implied locking gunk in the storage api.
On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisher da...@chromium.org wrote:
The recent discussion about the storage mutex for Cookies and LocalStorage
got me thinking
Perhaps instead of trying to build implicit locking
If this feature existed, we likely would have used it for offline Gmail to
coordinate which instance of the app (page with gmail in it) should be
responsible for sync'ing the local database with the mail service. In the
absence of a feature like this, instead we used the local database itself to
On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman micha...@google.comwrote:
If this feature existed, we likely would have used it for offline Gmail to
coordinate which instance of the app (page with gmail
On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman micha...@google.comwrote
at 12:32 PM, Maciej Stachowiak m...@apple.comwrote:
On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman
micha...@google.comwrote:
If this feature existed, we
1 - 100 of 161 matches
Mail list logo
