Re: [whatwg] API to delay the document load event
I think that there would be many uses for a mechanism that allows
developers to take part in letting the UA known when it is ready. For
example, we would use then when analyzing extension code server-side.
Another example would be systems that take screenshots of web pages for use
in browser start pages, or search results.
- a
On Mon, Apr 29, 2013 at 6:51 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/29/13 6:50 AM, James Graham wrote:
So far we have kept the model where the load event is auomatically
managed by the UA, rather than giving the developer direct control of it.
Developers already have direct control over the load event to the extent
being proposed, as far as I can tell. Consider this:
var blockers = [];
function blockOnload() {
var i = document.createElement(**iframe);
document.documentElement.**appendChild(i);
blockers.push(i.**contentDocument);
i.contentDocument.open();
}
function unblockOnload() {
blockers.pop().close();
}
Of course expecting web developers to come up with this themselves and
have to redo all this boilerplate is not reasonable, not to mention the
pollutes-the-DOM and uses-way-too-much-memory aspect of it all.
-Boris
Re: [whatwg] Installable web apps
On Mon, Jun 14, 2010 at 7:27 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 27 May 2010 18:22:03 +0200, Aaron Boodman a...@google.com wrote:
On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
meta name=application-name content=...
You're right -- that one does exist already within the page. And it is
a shame to waste these existing features.
The more I think about it, the more I start to agree that just using
the meta and link tags we already have (with perhaps one addition
for permissions), could work.
Let me think about it some more.
I think if we do more things it would make more sense to build them on top
of html manifest rather than creating some new kind of JSON-based format
that needs to be separately fetched.
Reviving ancient thread...
We are still interested in adding a lightweight concept of
'installation' to Chromium and Google Chrome that is separate from the
crx format. The attributes of an application that we like at the
moment are:
- a name
- a description
- a launch url
- icons of various sizes
- a set of permissions, such as geolocation and notifications
- a set of associated URLs (we would use this in Chromium to make
better decisions about how to group processes, and potentially how to
handle navigation)
To get a feel for the different approaches and tradeoffs, I've
implemented a prototype of this using the two of the approaches that
were discussed in this thread:
1. Embed metadata in the page, building off the existing support for,
eg, meta name=application-name:
head
meta name=application-name content=Pacman
meta name=application-description content=The arcade classic
meta name=application-url content=http://games.com/pacman;
meta name=application-permissions content=geolocation,notifications,...
meta name=application-urls content=pacman/
link rel=icon href=24.png sizes=24x24
link rel=icon href=48.png sizes=48x48
link rel=icon href=128.png sizes=128x128
2. Link to a separate metadata document:
head
link rel=application-definition content=application-definition.json
/head
// application-definition.json
{
name: Pacman,
description: The arcade classic,
launch_url: http://games.com/pacman;,
icons: [
{
url: 48.png,
width: 48,
height: 48
},
{
url: 128.png,
width: 128,
height: 128
}
],
permissions: [
{ name: geolocation },
{ name: notifications },
... etc ...
],
urls: [
pacman/
]
}
In both cases, there would also be an associated navigator API:
void navigator.installApplication();
bool navigator.isInstalled;
I did not pursue adding the application definition to the existing app
cache manifest format. I discussed that with Chromium's resident
appcache expert and he was against it because he felt that the two
things were really completely different features and preferred keeping
them decoupled.
As I see it, here are the advantages of the two approaches:
1:
- a bit simpler
- builds off the existing features in the platform
2:
- DRY-er (doesn't repeat the same information on multiple pages of the
application)
- Easier for third-party agents (eg search engines) to consume
(doesn't require an HTML parser)
- The browser doesn't have to load a page to consume
Based on this, I'm liking #2 better as a path forward and am going to
push to get an implementation of this working in Chromium.
Are there any other vendors interested in doing something similar? If
so, I'd like to hash out the details so we end up with
interoperability.
Thanks,
- a
Re: [whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)
On Wed, Jul 7, 2010 at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Jul 7, 2010 at 5:28 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: This is about the fourth time I've said it here. Can the person in charge of writing the slow and buggy ajvascript on the HTML 5 spec please remove that? The problem is that that whatwg page causes freezes and crashes in Firefox. i When it doesn't throw errors, it freezes Firefox. This is is unfair to the the user, who might not anticipate when clicking on a link. Launching Task Manager... Use the multipage version of the spec instead. The one-page version doubles as a browser stress-test. People do sometimes send links to the one-page version; you'll just have to watch out for that and correct it yourself. I hear this every so often. Do we really need the spec to double as a browser stress test? I mean, there are actual test suites nowadays. I just want to read the spec. - a
Re: [whatwg] Installable web apps
On Tue, Jun 8, 2010 at 1:17 PM, Adam Barth w...@adambarth.com wrote: Yes, doing this correctly is quite subtle. I'd pitch the feature more as developer connivence rather than for security. Apps that are hosted in the same origin need to trust each other. That is what we were planning on. - a
Re: [whatwg] Installable web apps
On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2010-05-26 19:10, Aaron Boodman wrote: On Wed, May 26, 2010 at 4:30 AM, Henri Sivonenhsivo...@iki.fi wrote: There's a zip file with a .crx extension that contains an icon, a permission manifest and potentially the code of the app (Building a serverless app). When the .crx file contains the code of the app, a .crx file is essentially like a .wgt file (which is what Opera has been pushing and already has a catalog site http://widgets.opera.com/ ) except with the manifest XML exorcised and replaced with JSON. This isn't really the point of this mail, but I just want to point out that there are more differences between wgt and crx than the format of the manifest file. The most important is that the identify of a crx file is a public key, and all crx files are self-signed by their key. This makes a crx file's identity unforgeable. There are, however, a lot of similarities between your proposal and widgets. I compared the manifests of both crx and widgets, and I believe the metadata included in crx maps to that in widgets as follows: *Chrome Manifest* | *Widgets Manifest* (implied) | widget viewmodes=windowed name | name version | widget version=... icons | icon src= - 24 | ... height=24 width=24 - 128 | ... height=128 width=128 permissions | feature web_content | access - enabled | (implied) - origin | ... origin=... - paths | N/A - what's the purpose of this, why is it needed? launch: | Default start file, e.g. index.html, or - web_url | N/A - local_path | content src=... Digital signatures are also supported in widgets. Are there any limitations that you are aware of with widgets-digsig compared with crx signatures that might make them unsuitable? Maybe, but I think that debate should be separate from this thread. I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To install a Web application, the user would navigate to the app's URL and create an application bookmark. For Chrome this isn't the UX we want. We want users to click a link in the content area and be presented with an install dialog. We think that going to something in the browser to applicationify a web app is too indirect and that many users will not get it. That was the user experience offered by Safari 4 beta's experimental Save as Web Application feature and Mozilla Prism. I can understand why that is perceived as suboptimal for many users. But they had the advantage of allowing the user to turn any website they wanted into an application, whereas your proposed model depends on the site explicitly providing an application to install. There are benefits to both models. That said, I think there is room to support multiple models of installation (or bookmarking, or whatever you want to call it), though. Indeed. If it's still deemed useful to be able to pre-grant permissions, I think the app should, again instead of installed zip files, uselink rel=something to point to a manifest that shows what the apps wishes to be pre-granted. When the features to be granted have obvious JavaScript entry points from the window object (e.g. navigator.geolocation), the JavaScript names of those entry points should be used to identify the features in the manifest in order to avoid having to standardize separate permission names. We have a growing set of metadata you're trying tolink to: - Icons link rel=icon sizes=24x24 href=icon.png My concern with reusing favicons is that some browsers support changing them at runtime, so they can be overloaded to show status information. We were actually planning on doing this in Chrome too, even for the larger sizes. Also, it seems weird to repeat the application information on every webpage in an app, so I prefer linking off to a separate resource anyway. I wonder if it would be too much of a hack to only use the icon listed in the HTML for use in the launch/bookmark UI, and only display runtime changes to it in the tab/window titlebar. - Application name (you didn't mention this, but I think it is nice to have distinct from thetitle, which is often overloaded with status information) meta name=application-name content=... You're right -- that one does exist already within the page. And it is a shame to waste these existing features. The more I think about it, the more I start to agree that just using the meta and link tags we already have (with perhaps one addition for permissions), could work. Let me think about it some more. - Any permissions Not yet available. To me, this all leads to the following proposal: html head !-- for UAs that want a button in the browser chrome to appify -- link rel=application-description href=myapp.json
Re: [whatwg] Installable web apps
Hello Henri, Thank you for the thoughtful mail. I really appreciate you taking the time to understand the proposal. On Wed, May 26, 2010 at 4:30 AM, Henri Sivonen hsivo...@iki.fi wrote: I don't think it's a given that everyone who is talking about installable Web apps is talking about HTTP plus cache, although I wish everyone were talking about that. Take a look at http://code.google.com/chrome/apps/docs/developers_guide.html There's a zip file with a .crx extension that contains an icon, a permission manifest and potentially the code of the app (Building a serverless app). When the .crx file contains the code of the app, a .crx file is essentially like a .wgt file (which is what Opera has been pushing and already has a catalog site http://widgets.opera.com/ ) except with the manifest XML exorcised and replaced with JSON. This isn't really the point of this mail, but I just want to point out that there are more differences between wgt and crx than the format of the manifest file. The most important is that the identify of a crx file is a public key, and all crx files are self-signed by their key. This makes a crx file's identity unforgeable. I think neither .wgt nor serverless .crx apps are Web apps. I think they are local apps built with Web technologies. I think an essential part of an app being a *Web* app is that you navigate in your Web browser to a URL pointing to somewhere out there *on the Web* and the application UI loads into your browser from out there. Now, somewhere out there may not be reachable at all times. However, I think stuffing the app into a zip file is an un-Webby way of making an app available offline. I think the Webby way is reading the files of the app from cache when offline but automatically refreshing the client-side files of the app to the latest versions by retrieving them from the server when connectivity works. Thus, I think offline availability should be based on the HTML5 app cache--not on installed zip files. I completely agree that app cache is a more webby way of making apps available offline than packaging. In particular, app cache preserves the ability to deep-link into an application, which is an important characteristic of the web. The source of our support for packaged applications is that we have gotten a lot of feedback from developers that find packages a very convenient way to develop applications that work offline. I think the reason is that packages are conceptually much simpler than app caches. That said, I think this is mainly a lack of good tool support for app cache and good documentation, and I think it can eventually be overcome. For now, I would like to focus on live web apps, not packaged local apps. I think it follows that to install a Web app, you navigate to its URL and bookmark it. There is no need to have an icon in a zip file for this: HTML5 already provides link rel=icon sizes=... that the app can use to declare its icon, which can be pinned to cache upon bookmarking. So far, nothing new to design. A plain bookmark doesn't elevate the bookmarked app sufficiently to be special in the system app switcher (like Prism) or inside the tab system of the browser (like Firefox 4 application tabs). A plain bookmark also doesn't pre-grant any permissions or ensure that the app stays in the cache. I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To install a Web application, the user would navigate to the app's URL and create an application bookmark. For Chrome this isn't the UX we want. We want users to click a link in the content area and be presented with an install dialog. We think that going to something in the browser to applicationify a web app is too indirect and that many users will not get it. That said, I think there is room to support multiple models of installation (or bookmarking, or whatever you want to call it), though. To work with the security model of the Web, an application bookmark should probably be considered to bookmark and origin as opposed to bookmarking just one URL. I think having an application bookmark should have the following effects by default: 1) The application bookmark should be displayed to the user in a distinct way compared to regular bookmarks (regular bookmarks are semi-obsolete anyway). 2) Restrictions on resource usage should be very relaxed or entirely removed for an origin that has an application bookmark. That is, the app should be able to consume a lot of local storage space. Rationale: If the user is using an app enough to make an app bookmark for it, the user probably considers the app at least semi-non-hostile and prefers to let the app to be able to do its thing at least in ways that don't involve relaxing privacy. 3) Restrictions on the app leaving evidence of its use on the client computer should be lifted. That is, the
Re: [whatwg] Installable web apps
On Wed, May 26, 2010 at 10:10 AM, Aaron Boodman a...@google.com wrote: !-- for UAs that want a button in the Chrome to appify -- button onclick=navigator.installApplication()install/button Sorry, I meant for UAs that want a button in the content area to appify. - a
[whatwg] Installable web apps
This has come up before, but since Google has officially announced the project at IO, and Mozilla has voiced interest in the idea on their blog, I felt like it might be a good to revisit. Google would like to make today's web apps installable in Chrome. From a user's point of view, installing a web app would: - Give it a permanent access point in the browser with a big juicy icon - Allow the browser to treat a web app as a conceptual unit (eg give it special presentation, show how much storage it uses) - Add some light integration with the OS - (optionally) Pre-grant some permissions that would otherwise have to be requested one-at-a-time (eg geolocation, notifications) - (optionally) Grant access to some APIs that would otherwise be inaccessible (eg system clipboard, permanent storage) There is some more background on our thinking at these two URL: http://code.google.com/chrome/apps/ http://code.google.com/chrome/apps/docs We have started implementing this using Chrome's current extension system. However, we'd like it if installation could eventually work in other browsers. Is there any interest from other vendors in collaborating on the design of such a system? Thanks, - a
Re: [whatwg] LocalStorage in workers
On Wed, Sep 16, 2009 at 3:36 PM, Jeremy Orlow jor...@chromium.org wrote: Code wise, what Robert suggested is MUCH simpler. Almost for free in WebKit. Creating an asynchronous access method and exposing this in the page is much more complex. It also defeats the main purpose of LocalStorage (which is to be a simple, light weight way to store data). I do not buy that creating an asynchronous access method and exposing this in the page ... defeats the main purpose of LocalStorage (which is to be a simple, light weight way to store data) Having one async callback doesn't make the API hard to use. Callbacks are easy to work with in JS. Adding one is not the end of the world by a long shot. That said, I suppose it is probably wise to chase down option 3), if people are motivated, so that we don't end up with *three* name/value storage APIs. - a
Re: [whatwg] Application defined locks
On Fri, Sep 11, 2009 at 9:03 AM, Mike Shaver mike.sha...@gmail.com wrote: Aaron, You're right, my recollection is quite incorrect. My apologies for unfairly describing the origin of the proposal. I forgive you :). In fact, the many design changes to the database API were made precisely because they made it more webby, within the constraints of being SQL-based. As on example, the fully asynchronous API was done to avoid blocking the UI thead, something that is important for web browsers. All of this played out on the WhatWG mailing list over several months with input from many vendors, but admittedly, mostly Google and Apple (not for want of other input -- just because we seemed to be the two that most wanted this feature). Do you agree with Jeremy that Database is too far along in terms of deployment to have significant changes made to it? Given that we're still hashing our major philosophical elements with respect to transactionality and locking in parts of HTML5, I can imagine it being quite desirable to make Database conform to whatever model we settle on. Does the localStorage mutex plus onbeforeunload plus Database transaction collision equal deadlock?, etc. I don't think that is what Jeremy was saying (emphasis mine): On Fri, Sep 11, 2009 at 1:26 AM, Jeremy Orlow jor...@chromium.org wrote: In theory. In practice, once a vendor has shipped something, it's somewhat sacred. Once multiple have, it's even more so. This is somewhat unfortunate, in my opinion, since very few people are using localStorage or DB yet, but it's now very difficult to correct even major problems in the spec. Picking another message from very early in the other thread that spawned this one: On Tue, Sep 8, 2009 at 1:08 AM, Jeremy Orlow jor...@chromium.org wrote: First of all, I'm not sure I agree that we're at the point where breaking compatibility is impossible. It really doesn't seem like it's terribly widely used, and what's implemented is based on an early draft of the spec. Yes, I agree that it's really unfortunate we didn't iron these problems out better before everyone implemented it, but if LocalStorage changed today, it definitely wouldn't break the web. (Of course, it's possible that we would be breaking the web by the time the next gen of the major browsers ship.it's hard to know for sure.) Throughout, he has reiterated his belief that we are *not* too far along to change the design. I think this thread has gotten long enough and involves enough people that every possible position has already been laid out, and we continue only out of brownian motion. - a
Re: [whatwg] Application defined locks
On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisherda...@chromium.org wrote:
I imagine a simple lock API:
window.acquireLock(name)
window.releaseLock(name)
I do not think it is a good idea to allow long-lived (past a stack
frame) locks on the types of things we've been discussing (local
storage, databases, etc).
This API seems like it could be used to allow LocalStorage to be usable from
workers. Also, as we start developing other means of local storage (File
APIs), it seems like having to again invent a reasonable implicit locking
system will be a pain. Perhaps it would just be better to develop something
explicit that application developers can use independent of the local
storage mechanism :-)
There would presumably have to be a separate name value for each API,
though, right? So we're talking about the difference between:
window.acquireLock(localStorage, function() {
...
});
and:
window.acquireLocalStorage(function() {
...
});
It doesn't seem like much of a win for reusability IMO.
It may be the case that we want to only provide acquireScopedLock (or
something like it) to enforce fine grained locking, but I think that would
only force people to implement long-lived locks by setting a field in
LocalStorage.
Do you have an example of a place where we want to allow long-lived locks?
- a
Re: [whatwg] Application defined locks
On Wed, Sep 9, 2009 at 11:23 AM, Darin Fisherda...@chromium.org wrote:
On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman a...@google.com wrote:
There would presumably have to be a separate name value for each API,
though, right? So we're talking about the difference between:
window.acquireLock(localStorage, function() {
...
});
and:
window.acquireLocalStorage(function() {
...
});
It doesn't seem like much of a win for reusability IMO.
I wanted to leave it up to the app developer to choose the name so that they
could define how the lock is interpreted.
For example, they might want to partition the keyspace for local storage and
have separate locks for separate keys. Or, they might want to have a single
lock that is inclusive of several storage mechanisms: LocalStorage and
FileAPI.
Besides, once we have an explicit locking API, why not just be generic and
give it a name divorced from LocalStorage or any kind of storage features
for that matter? Locking can be useful to other applications that do not
even use local storage...
I see.
So you are suggesting the localStorage could have zero concurrency
guarantees and it is simply up to the developer to arrange things
themselves using this new primitive.
That is an interesting idea. You're right that it overlaps with the
ideas that inspired shared workers, and the global script proposal.
- a
Re: [whatwg] Application defined locks
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodmana...@google.com wrote: I see. So you are suggesting the localStorage could have zero concurrency guarantees and it is simply up to the developer to arrange things themselves using this new primitive. That is an interesting idea. You're right that it overlaps with the ideas that inspired shared workers, and the global script proposal. Ok, after thinking about this for a day, I'm going to say I think this is a very cool idea, and a worthwhile addition, but I don't think it should substitute for having the local storage API work correctly by default. The web platform is supposed to work for developers of all experience levels. If we make local storage have no concurrency guarantees, it will seem like it works in the overwhelming majority of cases. It will work in all SELUAs, and it will only NOT work in MELUAs in cases that are basically impossible to test, let alone see during development. We have tried hard with the design of the web platform to avoid these sort of untestable non-deterministic scenarios, and I think it is to the overall value of the platform to continue this. Therefore, my position continues to be that to access local storage, there should be an API that asynchronously acquires exclusive access to storage. - a
Re: [whatwg] Application defined locks
On Wed, Sep 9, 2009 at 9:13 PM, Darin Fisherda...@chromium.org wrote: If I call showModalDialog from within a database transaction, and then showModalDialog tries to create another database transaction, should I expect that the transaction can be started within the nested run loop of the modal dialog? By definition, in that case, the second transaction would not start until the dialog was closed. If not, then it may cause the app to get confused and never allow the dialog to be closed (e.g., perhaps the close action is predicated on a database query.) That is true, but it is an easily reproducible, deterministic application bug. It also doesn't destabilize the environment -- by making tabs or dialogs unclosable or whatever. Nested loops suck. showModalDialog sucks :-) Fair enough. - a
Re: [whatwg] Application defined locks
On Wed, Sep 9, 2009 at 10:07 PM, Darin Fisherda...@chromium.org wrote: Well, the problem is that the creator of the transaction and the code associated with the showModalDialog call may not be related. The showModalDialog code might normally be used outside the context of a transaction, in which case the code would normally work fine. However, if triggered from within a transaction, the dialog would be stuck. I agree that is possible. It at least meets the bar that every time this code path is executed it will behave exactly the same way (we have spec'd things before where we didn't even get this far, because of gc issues). But it would be better to not have weird edge cases like this in uncommon paths. OTOH, it seems like showModalDialog() is just a sharp edge that is likely to hurt you no matter what. Even with your proposal, unless you carefully arranged things in preparation for showModalDialog(), you could get stuck the same way. - a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Fri, Sep 4, 2009 at 12:02 AM, Chris Jonescjo...@mozilla.com wrote:
I propose adding the functions
window.localStorage.beginTransaction()
window.localStorage.commitTransaction()
or
window.beginTransaction()
window.commitTransaction()
I think this is a good idea! I would modify it to follow the pattern
set by the current SQLDatabase proposal, to have a callback, like
this:
window.localStorage.transaction(function() {
// use local storage here
});
I'm against having explicit begin/commit methods for the same reason
as I am for the SQLDatabase feature:
- It is easy to forget to commit
- The most likely paths in an application to be wrong are ones that
are rarely run
- Therefore many applications will contain uncommon paths that end up
hung (responsive, but still unable to make forward progress) and with
uncommitted data
But those issues are easily fixable with the callback model above.
On Fri, Sep 4, 2009 at 12:32 AM, Jeremy Orlowjor...@chromium.org wrote:
I actually think the idea of
throwing an exception whenever there's a serialization problem could be very
compelling, and could keep the door wide open for future performance
enhancements.
What problem would this solve? It seems like it would require
cross-app coordination to avoid exceptions.
On Fri, Sep 4, 2009 at 12:32 AM, Jeremy Orlowjor...@chromium.org wrote:
Note that if we do decide to break backwards compatibility, there are some
other things we should consider...but I won't bring those up unless we do
decide to move in this direction.
Btw, I want to make it clear that I take the idea of
breaking compatibility VERY seriously. I know LocalStorage is fairly well
adopted and that changing this would be pretty major. But having a
cross-event-loop, synchronous API is really a terrible idea. And changing
it now will be easier than changing it later.
I think it is possible to make this change with a very small breaking
change. Just add window.localStorage.transaction() and keep the rest
of the API as-is. Existing implementations can add the method, but
supporting using window.localStorage without transaction(), too.
- a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodmana...@google.com wrote:
On Fri, Sep 4, 2009 at 12:02 AM, Chris Jonescjo...@mozilla.com wrote:
I propose adding the functions
window.localStorage.beginTransaction()
window.localStorage.commitTransaction()
or
window.beginTransaction()
window.commitTransaction()
I think this is a good idea! I would modify it to follow the pattern
set by the current SQLDatabase proposal, to have a callback, like
this:
window.localStorage.transaction(function() {
// use local storage here
});
We have discussed similar APIs in the past. Something like a:
window.getLocalStorage(function (storage) {
...use storage...
});
This is nice because it can be expanded to something like:
window.getSharedItems(window.SHARED_ITEM_LOCALSTORAGE |
window.SHARED_ITEM_COOKIES, function (...) { ... });
to let you access both cookies and localStorage safely at the same time.
I think worrying about safely accessing cookies is a bit of
over-design. As has been pointed out, cookies don't work correctly
today and the wheels haven't fallen off yet.
I think a solution for localStorage that doesn't fix cookies is fine.
However, this requires breaking compatibility with existing syntax,
something that seems impossible at this point given that Microsoft has
shipped localStorage. I know Hixie has asked them in the past about
how they plan to deal with the mutex problem, but I'm not sure if an
answer has been received as of yet.
I addressed this at the end of my last message. Specifically, I suggest:
interface LocalStorageTransactionCallback {
void handleEvent(); // note: no arguments!
};
interface LocalStorage {
...
// LocalStorage can only be accessed inside this callback. Access outside
// of it will raise an exception, except in some browsers that support such
// behavior for legacy reasons.
void transaction(LocalStorageTransactionCallback callback);
...
};
With this, there is no need to change anything about the current API.
The only change is the addition of the new transaction() method.
- a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodmana...@google.com wrote:
On Fri, Sep 4, 2009 at 12:02 AM, Chris Jonescjo...@mozilla.com wrote:
I propose adding the functions
window.localStorage.beginTransaction()
window.localStorage.commitTransaction()
or
window.beginTransaction()
window.commitTransaction()
I think this is a good idea! I would modify it to follow the pattern
set by the current SQLDatabase proposal, to have a callback, like
this:
window.localStorage.transaction(function() {
// use local storage here
});
We have discussed similar APIs in the past. Something like a:
window.getLocalStorage(function (storage) {
...use storage...
});
This is nice because it can be expanded to something like:
window.getSharedItems(window.SHARED_ITEM_LOCALSTORAGE |
window.SHARED_ITEM_COOKIES, function (...) { ... });
to let you access both cookies and localStorage safely at the same time.
I think worrying about safely accessing cookies is a bit of
over-design. As has been pointed out, cookies don't work correctly
today and the wheels haven't fallen off yet.
I think a solution for localStorage that doesn't fix cookies is fine.
However, this requires breaking compatibility with existing syntax,
something that seems impossible at this point given that Microsoft has
shipped localStorage. I know Hixie has asked them in the past about
how they plan to deal with the mutex problem, but I'm not sure if an
answer has been received as of yet.
I addressed this at the end of my last message. Specifically, I suggest:
interface LocalStorageTransactionCallback {
void handleEvent(); // note: no arguments!
};
interface LocalStorage {
...
// LocalStorage can only be accessed inside this callback. Access outside
// of it will raise an exception, except in some browsers that support such
// behavior for legacy reasons.
void transaction(LocalStorageTransactionCallback callback);
...
};
With this, there is no need to change anything about the current API.
The only change is the addition of the new transaction() method.
While this keeps existing IDL intact, it still breaks any existing
pages, which is the real concern for any browser vendor I would think.
Not necessarily.
The second half of my proposal is that vendors who currently implement
local storage can choose to continue to allow access to it outside of
the transaction() callback. It seems like this would work fine for
single-event-loop browsers, right?
- a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Tue, Sep 8, 2009 at 1:20 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodmana...@google.com wrote:
On Fri, Sep 4, 2009 at 12:02 AM, Chris Jonescjo...@mozilla.com wrote:
I propose adding the functions
window.localStorage.beginTransaction()
window.localStorage.commitTransaction()
or
window.beginTransaction()
window.commitTransaction()
I think this is a good idea! I would modify it to follow the pattern
set by the current SQLDatabase proposal, to have a callback, like
this:
window.localStorage.transaction(function() {
// use local storage here
});
We have discussed similar APIs in the past. Something like a:
window.getLocalStorage(function (storage) {
...use storage...
});
This is nice because it can be expanded to something like:
window.getSharedItems(window.SHARED_ITEM_LOCALSTORAGE |
window.SHARED_ITEM_COOKIES, function (...) { ... });
to let you access both cookies and localStorage safely at the same time.
I think worrying about safely accessing cookies is a bit of
over-design. As has been pointed out, cookies don't work correctly
today and the wheels haven't fallen off yet.
I think a solution for localStorage that doesn't fix cookies is fine.
However, this requires breaking compatibility with existing syntax,
something that seems impossible at this point given that Microsoft has
shipped localStorage. I know Hixie has asked them in the past about
how they plan to deal with the mutex problem, but I'm not sure if an
answer has been received as of yet.
I addressed this at the end of my last message. Specifically, I suggest:
interface LocalStorageTransactionCallback {
void handleEvent(); // note: no arguments!
};
interface LocalStorage {
...
// LocalStorage can only be accessed inside this callback. Access outside
// of it will raise an exception, except in some browsers that support
such
// behavior for legacy reasons.
void transaction(LocalStorageTransactionCallback callback);
...
};
With this, there is no need to change anything about the current API.
The only change is the addition of the new transaction() method.
While this keeps existing IDL intact, it still breaks any existing
pages, which is the real concern for any browser vendor I would think.
Not necessarily.
The second half of my proposal is that vendors who currently implement
local storage can choose to continue to allow access to it outside of
the transaction() callback. It seems like this would work fine for
single-event-loop browsers, right?
But that results in code that works in one browser, but not another,
defeating the whole point of having a standard.
Would you be fine with having pages that work fine in Firefox and IE,
break in Chrome?
I don't really see another option. People on the Chrome team are
saying it may be impractical to implement the spec as-is. Presumably
Firefox is unwillingly to break backward compatibility. If both of
these are true, we are headed for a split.
In this case, I don't think it is a big deal. My proposed API change
is so minor that it is trivial to handle in code:
function doStorageStuff() {
... use window.localStorage ...
}
if (localStorage.transaction)
localStorage.transaction(doStorageStuff);
else
doStorageStuff();
- a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Tue, Sep 8, 2009 at 2:02 AM, Robert O'Callahanrob...@ocallahan.org wrote: Looking back over previous threads on the storage mutex, I can't seem to remember or find the reason that implementing the storage mutex for cookies can't easily be done with a mutex per domain. Ian pointed out this approach breaks if you can make synchronous script calls across origins (e.g. across IFRAME boundaries), but can you actually make such calls? Or if you can (NPAPI?), can we just declare that those APIs release the storage mutex? I believe that synchronous cross-origin calls are possible a variety of ways. Here is one way I found with a quick test: Resize an iframe element. window.onresize is fired synchronously inside the frame. I bet there are others. I know that setting document.domain makes this tricky because it synchronously enables new cross-domain interactions, but can't we handle that by declaring that setting document.domain releases the storage mutex? All of these different ways that the storage mutex gets implicitly released lead to weird behavior in edge cases. In my opinion, it would be better to fix the API in a clean way than keep patching it like this. - a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Tue, Sep 8, 2009 at 11:23 AM, Chris Jonescjo...@mozilla.com wrote: In general, I agree with Rob about this proposal. What problem with storage mutex as spec'd today does your proposal solve? The spec requires a single storage mutex for the entire UA. Therefore in a MELUA a web page can become unresponsive while waiting for some other page to give up the lock. This is not good and something we have tried to avoid everywhere else in the spec. Attempts to address this by doing per-origin locks wind up with deadlocks being possible. I'm eagerly willing to concede explicit beginTransaction()/commitTransaction() for a window.transaction() wrapper that implicitly does those. Cool, that is the only point I was trying to make. Aaron Boodman wrote: On Tue, Sep 8, 2009 at 1:41 AM, Robert O'Callahanrob...@ocallahan.org wrote: What is the intended semantics here? Chris' explicit commitTransaction would throw an exception if the transaction was aborted due to data inconsistency, leaving it up to the script to retry --- and making it clear to script authors that non-storage side effects during the transaction are not undone. How would you handle transaction aborts? Calls to transaction() are queued and executed serially per-origin with exclusive access. There is no such thing as a transaction abort because there cannot be consistency problems because of the serialized access. No, transactions can still fail. They can fail in ways immediately hidden from the script that requested them if the UA has to interrupt the conceptually executing transaction in the ways enumerated in a separate branch of this thread. Later script executions can observe inconsistent state unless more is specified by your proposal. Transactions can also fail visibly if write-to-disk fails (probably also in other ways I haven't considered). It's not clear what should happen wrt to your proposal in this case. It sounds like you're talking about these issues that you listed a bit earlier: * clear private data * close tab * quit UA * slow script timeout * store-to-disk failure * crash Right? If so, I agree with roc's responses to them that they could probably be handled without surfacing errors to the developer. OTOH, I'm not really against adding the concept of fallibility here. That wasn't really my point. Mainly, I just think that: a) We can't have synchronous access to the storage API b) We should not have an API that requires an author to explicitly begin and commit transactions I have to admit that I didn't closely read the Web Database spec before making the OP. Like Rob, my scan of the text led me to believe that it provided an API to asynchronously execute SQL free from script side effects. It does *not*. Arbitrary side-effecty script statements can execute within Web Database transactions. Yeah, I meant to correct Rob on that. And these transactions can be synchronous. And like my OP concerning localStorage, Web Database transactions are allowed to fail by the spec. Right. In fact, I believe that the Synchronous database API describes the same transaction semantics as I proposed in the OP. That spec adds implicit begin/commitTransaction and read-only transactions, but otherwise the semantics are the same. So I'd like to amend my original proposal to be Use Synchronous Web Database API transaction semantics. Except do not offer readTransaction: a transaction is implicitly a read-only transaction if only getItem() is called on localStorage from within localStorage.transaction(). Agree. That is what I was trying to propose, too. I'm not sure where we disagree :). Is it just that my proposal has no concept of errors? I'm not against adding them, mainly I was trying to keep my proposal simple for purposes of discussion. Note: you're mentioning synchronous transactions here. I think that the callback for localStorage.transaction() *must* be run asynchronously to avoid blocking on access to the storage. I presume this is what you meant. Right? - a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Tue, Sep 8, 2009 at 12:02 PM, Jonas Sickingjo...@sicking.cc wrote: On Tue, Sep 8, 2009 at 11:53 AM, Aaron Boodmana...@google.com wrote: On Tue, Sep 8, 2009 at 11:23 AM, Chris Jonescjo...@mozilla.com wrote: In general, I agree with Rob about this proposal. What problem with storage mutex as spec'd today does your proposal solve? The spec requires a single storage mutex for the entire UA. Therefore in a MELUA a web page can become unresponsive while waiting for some other page to give up the lock. This is not good and something we have tried to avoid everywhere else in the spec. Attempts to address this by doing per-origin locks wind up with deadlocks being possible. How could this happen. It certainly does sound scary to have a bunch of locks that can be grabbed in arbitrary order, but I can't off the top of my head think of any ways where deadlocks can happen. From a Hixie mail way back in March: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018991.html snip If it can be shown that it is not ever possible for script in one origin to synchronously invoke script in another origin, then I guess we could have per-origin locks instead of a single lock. /snip Here are two cases I know of where it is possible to have synchronous script execution across origins: * Plugins. It is possible for script to invoke a plugin function in one frame, and for the plugin to synchronously execute script in another frame. We have addressed this in the spec by saying that invoking a plugin releases the storage mutex, but that doesn't really solve the problem. We are exchanging violation of run-to-completion for deadlock. I guess it is an improvement, but it is still a bug. * In WebKit, onresize is invoked synchronously. You can cause cross-origin synchronous script execution by resizing an iframe. AFAIK, the spec does not disallow this event from being synchronous. I found the second case after only a few minutes of thinking about it. I suspect there are more since it was never a design goal to prevent synchronous script execution across origins. We could patch each case like this by releasing the mutex, but each time we do that, we poke another hole in run to completion. I also suspect such patches will be difficult to maintain. Even if we update implementations to invoke onresize asynchronously, how confident can we be in interactions between such unrelated components as event dispatch and storage continuing to work correctly? Finally, even with these hacks, we have problems. In a MELUA (I love that acronym!), with per-origin local storage mutexes, we still can end up with unresponsive UI because it is possible to have the same origin running on different event loops. Adding an asynchronous step to acquire the mutex neatly solves all these problems. We get run-to-completion, and we never block an event loop on waiting for a mutex. On Tue, Sep 8, 2009 at 12:39 PM, Chris Jonescjo...@mozilla.com wrote: I think we all agree that a script may fail to modify localStorage in some situations (irrespective of global mutex vs. per-domain mutex). One camp, wanting mutex semantics, would prefer to pretend that the failures never happen and let scripts clean up the mess (partially-applied changes) if they do occur. This is semantically broken, IMHO. The second camp, wanting transaction semantics, explicitly acknowledge to web authors that localStorage is fallible, guarantee that modifications to localStorage are atomic, and notify scripts when modifications can't be made atomically. This is the same approach taken by Web Database. IMHO, this is much better semantically because (i) it gives web apps stronger guarantees; and (ii) it makes the discussion about global mutex/per-domain mutex/non-blocking an implementation issue rather semantic issue, as it should be. Can those in the first camp explain why mutex semantics is better than transaction semantics? And why it's desirable to have one DB spec specify transaction semantics (Web Database) and a second specify mutex semantics (localStorage)? Ok, I don't have a strong preference on this. Transaction semantics seem better to me, but only marginally so. - a
Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
On Tue, Sep 8, 2009 at 4:27 PM, Chris Jonescjo...@mozilla.com wrote: With my proposal, a web app that tests whether localStorage is available with |window.localStorage === undefined| would conclude that it's not, because that object would not be available until |window.transaction| or whatever was accessed. In Jeremy's and Benjamin's proposals, a web app using that would check would conclude that window.localStorage *is* available. Aha, I had missed this (clever) idea in your original proposal. I also do not have a strong opinion on having vs not having this as part of the API. - a
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 8:23 PM, Linus Upsonli...@google.com wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog which reads, Please choose what to delete so that web sites will continue to work. The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. I see what you're saying. If the web is able to use local storage and UAs aren't allowed to prune it, then the storage used by web browsers tends to grow forever. If you want the web to continue to be completely stateless, there is no way around this. On Thu, Aug 27, 2009 at 10:18 AM, Erik Kayerik...@google.com wrote: I also think this thread is jumping to hyperbole about how the UA would be deleting data arbitrarily. Reasonable cache eviction algorithms won't cause much of a problem here. Do you use offline email all of the time? Guess what? It won't be evicted. Did you recently make change to an offline document that you didn't sync? It won't be evicted. The things that are problematic are the things which are accessed infrequently yet only exist in this local storage. See my argument above for why I think local storage isn't a great solution to offline only data anyway. I agree you could get 95% of the way there. But I can prove that this problem will happen in the real world. All I have to do is have a user with a small enough disk (an iPhone) and enough applications storing precious data. No amount of heuristics will stop the UA from either accidentally deleting something the user wanted, or asking the user to choose something to delete in this case. On Thu, Aug 27, 2009 at 10:18 AM, Erik Kayerik...@google.com wrote: What kinds of applications do people write against non-prompted Flash storage? As far as I can tell, it's used as a way to store cookies that are less likely to be deleted. It's not for data that the user would define as precious. How do I get data out of Flash storage? How do I back it up? Nobody does because they don't care and there isn't a use case driving this need today. The data isn't precious. Sure, but we're only having this conversation at all because we believe that the existing technology isn't meeting some use cases. People want to build offline applications based on web technology, and those apps tend to want to store data persistently and have it be treated as precious. If you accept this use case exists, and you accept that it is not possible for a UA to automatically make this decision, then we're just left with how to get the user involved. I think we are seeing, again, that there needs to be a difference between installed apps built on the web platform and the web as it is today. The web we know and love is stateless and should stay that way. Installed apps have state, and have to be actively managed by users. In that world, I think that the spec should be silent on what promises the UA makes wrt the data. It will be client-type-dependent. - a
Re: [whatwg] Web Storage: apparent contradiction in spec
On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org wrote: I still don't understand what use local storage has outside of 'cloud storage'. Even in the extensions use case (which I think is out of scope for this spec), there's no reason you can't sync user preferences and such to the cloud. The use case, though, is local storage, not cloud storage. Requiring cloud storage here kind of defeats the purpose and makes the API a lot harder to use. - a
Re: [whatwg] Web Storage: apparent contradiction in spec
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote: Ok, well I guess we should go ahead and have this discussion now. :-) Does anyone outside of Apple and Google have an opinion on the matter (since I think it's pretty clear where we both stand). FWIW, I tend to agree more with the Apple argument :). I agree that the multiple malicious subdomains thing is unfortunate. Maybe the quotas should be per eTLD instead of -- or in addition to -- per-origin? Malicious developers could then use multiple eTLDs, but at that point there is a real cost. Extensions are an example of an application that is less cloud-based. It would be unfortunate and weird for extension developers to have to worry about their storage getting tossed because the UA is running out of disk space. It seems more like if that happens the UA should direct the user to UI to free up some storage. If quotas were enforced at the eTLD level, wouldn't this be really rare? - a
Re: [whatwg] Global Script proposal.
On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com wrote: Another thing: From the proposal it seems it will be possible for the GlobalScript context to keep references to objects (DOM, JS data, etc) private to pages, and vice versa possible for pages to keep references to GlobalScript objects. This also opens up for a new way for independent pages finding and keeping references to each other's objects if they are somehow registered in the GlobalScript. When reloading a page there is also the additional dimension of the GlobalScript possibly holding references to objects both from the previous and current incarnation of the Document. In a way it seems GlobalScript usage will in practice merge the JS worlds of all participating pages, potentially including those already navigated away from. What are your thoughts on this? Don't all of these problems already exist with window.open() and frames? Can the existing solutions not be reused? - a
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote: Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? I think it is likely impractical for windows that have javascript access to each other to be on separate threads. The relationship between the global script and pages accessing it is similar to a parent windows and an iframe that are on the same origin, or to a window and a popup window on the same origin. Objects should be able to be freely passed across both sides. For example, the global script should be able to have a JavaScript object graph which represents some application state and share it (by reference) with its clients. I don't see how it is realistic to do this when the windows are separated by a thread boundary. Therefore, I would say it is totally valid for a UA to put a bunch of windows that want to use the same global script URL in different threads, but it should group them by thread. Each thread should get its own global script that is shared among the windows that are on that thread. - a
[whatwg] Removing versioning from HTML
[If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. - a
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 9:21 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: A feature that is not widely supported is a feature we authors can't depend on. If we're lucky, we can put in some extra effort to work around the lack and still deliver a decent experience. If we're not, we simply don't do what we wanted, or deliver something inferior that relies on technologies we *can* rely on. Clearly, but how does limiting the things that vendors can work on affect this one way or the other? I think there is an assumption that vendors will implement something solely because it is in the spec. This is not true, and can be verified by looking at history. Just yesterday, Jonas mentioned that Mozilla was less than enthused about implementing the bb tag from HTML5. Microsoft recently suggested they weren't happy with some of the new tags introduced in HTML5. And Ian has repeatedly said that he is not interested in writing fiction: he will only spec something that vendors will implement. The idea behind pushing something to the next version is that it gives implementors time to catch up to the spec and converge on what they support. This is good for people like me. ^_^ I don't think implementations will ever catch up. Partial mixed support is the natural state of a system where there are several completing implementations, and it is healthy. Some ideas aren't good. We shouldn't halt work on other things waiting for everyone to implement every idea. That is a recipe for stagnation. Instead, let some ideas die on the vine, and let growth occur in other places. If authors want a vendor to implement something, they will still be able to put pressure on the vendor to do that. In fact, that is exactly what happens today. Ian frequently says if you want that, please go talk to the vendors. In the meantime, there's certainly nothing preventing someone from exploring an idea. The fact that it won't make it into a spec *yet* doesn't mean you can't still discuss and refine it, or implement test versions of it in js, or anything else. In theory this is true. In practice, there is a lot of nice infrastructure setup at WhatWG that would be nice to reuse. Plus the WhatWG mailing list has become a very nice place for vendors to come together and discuss browser futures. What I am suggesting is that there should be no limit to the number of micro specs in a draft state concurrently at WhatWG. On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannonashannon1...@gmail.com wrote: If we never cut things off then the spec will really never be finished before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? - a
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 9:51 PM, David Levinle...@chromium.org wrote: It sounds like most of the concerns are about the 2nd part of this proposal: allowing a background page to continue running after the visible page has been closed. However, the first part sounds like it alone would be useful to web applications like GMail: Exactly. We have something like this for Chromium extensions (http://dev.chromium.org/developers/design-documents/extensions/background-pages), and it is really useful. The ability to reuse the web platform in the background context turns out to be really great for many little reasons. Like you can just call window.open(). Or include an NPAPI plugin. As a web platform feature, you could just do it like: html head background url=background.html ... /html The lifetime of the page could be refcounted by pages referencing it. - a
Re: [whatwg] In AppCache web apps, images from unpredictable domains won't load
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 as images will not be loaded at all. If foo.com has an image img src=http://bar.com/img.png; /, then according to the steps in http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel it will fail the load for the resource. For example, someone with an Offline Gmail client would never be able to see cross-domain images in emails, even when completely online. There's no workaround in the current spec. The workaround is for the gmail to download the images to gmails servers and then serve them from a google domain. Not as simple as simply being able to cache urls from other servers I agree, but doing multi domain application caches is very complicated from a security point of view so I think we wanted to stay clear of it for the first iteration of the spec. The spec already provides for loading resources not in the app cache from the network (across origins or not). It simply defaults to not allowing it. You have to opt-into the url prefixes you want to load from the network. I think we could fix this issue by simply changing the rules to default to allowing requests, and having the author mark the url prefixes he wants to blacklist from being loaded from the network. - a
Re: [whatwg] Browser Bundled Javascript Repository
2009/6/15 Ian Fette (イアンフェッティ) ife...@google.com: In the event of a collision there would be huge issues - imagine running someone else's script in your application. Basically XSS - someone could take over your app, steal passwords, do bank transactions on your behalf, etc. Collisions are made easier in plain text than in certs given that your input is not constrained. I think the idea was for browser vendors to select and include these libraries in the browser. So there isn't an obvious (to me) way for an attacker to use hash collisions to create an XSS. That said, I don't think content hashes are the right identifier. Using a sha-1 of a specific jquery version would prevent anyone from ever fixing critical bugs in it. There's be all this legacy content out there referring to an outdated version. - a
Re: [whatwg] Overriding functions in DOM Storage
This isn't a localstorage specific question, this is a general
question about overriding methods on any host object.
The comments about shooting yourself in the foot are good points, but
the same exact thing is possible on every single API in the entire
environment. It doesn't make sense to worry about them wrt local
storage, specifically.
FWIW, I think that Safari's behavior is correct (a bit weird, but
correct). But this is an area where there isn't good interop right now
across the board.
- a
On Tue, May 26, 2009 at 7:44 PM, Jeremy Orlow jor...@google.com wrote:
No one else (especially from Mozilla or Microsoft)? I was hoping to get a
consensus here (and maybe even things spelled out more clearly in the spec),
so that all the implementations could be headed in the same direction. :-)
On Fri, May 22, 2009 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On May 22, 2009, at 5:41 PM, Jeremy Orlow wrote:
What is the behavior of the following supposed to be?
window.sessionStorage.removeItem = function(x) { alert(Wait, this
works?); };
window.sessionStorage.removeItem('blah');
alert(typeof window.sessionStorage.removeItem);
Safari shows 2 alerts, and the second one says 'function'.
IE8 says object doesn't support this property or method if line 2 isn't
commented out. It returns type string when it is.
Mozilla also won't run if line 2 is there, but it returns type object for
line 3.
It seems to me that if IE8's behavior is correct, those parameters should
be marked as read-only since overriding them could only be used to shoot
yourself in the foot.
If Safari's implementation is correct (and it's good for the
implementations to be overridable), then I believe there needs to be some
safe way to make .clear() usable again. (Otherwise, once you override
removeItem() and clear(), there's not really any way to recover.) The spec
would also need to make it clear that removeItem, setItem, etc are special
and should not be serialized to disk.
Apologies if this is clear in the spec and I somehow missed it. But, if
not, I think a clarification might be necessary.
DOM methods are normally overridable. That would make the Safari behavior
correct. If we want the behavior to be different in this case, then the spec
should spell that out. Perhaps part of the issue here is that the definition
of the [NameSetter] extended attribute in Web IDL doesn't make clear whether
or not name setter behavior takes precedence over setting existing
predefined attributes or methods.
Regards,
Maciej
Re: [whatwg] Exposing EventTarget to JavaScript
I like the basic idea, but I think drawing too much inspiration from DOM events is a bad idea. What does it mean to capture a pure JS event? Further, the DOM event model has problems. It would be nice if events were first-class, not strings. It would be more idiomatic JS, I would argue, to do someObject.onClick.add(handler). - a
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:09 PM, Alex Russell slightly...@google.com wrote: Even in the XHR case, adding more than one listener is currently a pain. Part of the goal here would be to make event dispatch across lists of listeners as natural in JS as it is in DOM. Nit: I believe this has been fixed in XHR (it now supports addEventListener, if that's what you were referring to). - a
Re: [whatwg] localStorage + worker processes
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 use document.cookies instead of localStorage. I'd hate to see us radically change the API to support the worker case - I'd rather get rid of localStorage support from workers, or else just enforce a max time that a worker can hold the lock. I don't believe that. Adding one async callback is no inconvenience compared to the sad farce that is the document.cookie API. Also, localstorage has many benefits including structured storage and not getting sent to the server in every request. - a
Re: [whatwg] localStorage + worker processes
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: What we could do, is to have an API like getLocalStorage(callback); This function returns immediately, but will then call the callback function as soon as the localStorage becomes available and the lock been acquired. This would always happen asynchronously off the event loop, which means that once the callback returns the lock is released again. Funny, a few of us from Chromium were discussing a similar solution privately. Actually, I don't believe that it is required that the callback run asynchronously. All the callback is used for is establishing the lock lifetime explicitly, and we assume that this will usually make the lock lifetime short. So we can block while we wait for it to become available. This is just like the behavior today without workers. This new API I believe is good enough to be used both from workers and window contexts. We could maintain backward compatibility by not making it required on normal web pages, because our assumption has been that web pages won't hold the lock for long periods of time (because they wouldn't want to block the UI either). - a
Re: [whatwg] localStorage + worker processes
On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson atwil...@google.com wrote: That might work. Is it feasible for user agents to enforce limits on how long a callback is allowed to run holding the lock? That way workers can't starve normal pages from accessing their local storage. It seems like they could use the same time limit that is used for detecting/stopping runaway scripts in web pages. - a
Re: [whatwg] localStorage + worker processes
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 dead-locks.
Say that we make document.cookie behave the same way (to prevent
multi-process browsers like IE8 and chrome from having race
conditions). So that if you call document.getCookiesWithLock(callback)
we'll synchronously grab a lock and call the callback function. This
would cause two pages like the ones below to potentially deadlock:
Page 1:
getLocalStorage(function(storage) {
document.getCookiesWithLock(function(cookieContainer) {
storage.foo = cookieContainer.getCookie('cookieName');
});
]);
Page 2:
document.getCookiesWithLock(function(cookieContainer) {
getLocalStorage(function(storage) {
cookieContainer.setCookie('cookieName', storage.bar);
});
});
Good point. Ok, I agree that an asynchronous callback makes most sense
for this API.
- a
Re: [whatwg] localStorage + worker processes
I think the best option is to make access to localstorage asynchronous for workers. This reduces the amount of time a worker can hold the localstore lock so that it shouldn't be a problem for normal pages. It sucks to make such a simple and useful API aync though. - a
Re: [whatwg] Database feedback
On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson [EMAIL PROTECTED] wrote: We could have a .writeTransaction() and a .readTransaction(), where the former always run in isolation. Any preferences? My preference is for separating read transactions from write transactions. Then the API could throw if you tried to write in a read transaction. - a
Re: [whatwg] Workers and queue of events
On Tue, Nov 18, 2008 at 10:09 PM, Dmitry Titov [EMAIL PROTECTED] wrote: Ok, it makes sense for OOM to treat it as other OOM cases. If I may ask your opinion about related thing: SharedWorkers potentially would run cross-process. IPC can stop/stuck for many reasons, taret process can die in the midflight (killed by the user from TaskManager for example). I guess in this case Worker.postMessage() could still just return as if everything is ok, but nothing would happen. Is it the right behavior? I think it's OK to just drop messages in cases like this. - a
Re: [whatwg] JSON support for worker postMessage
If you support worker.sendMessage(stuff), where stuff is defined by convenience to be: whatever you are allowed to send JSON.stringify(), then you could expand this in the future to also allow blobs w/o changing anything about JSON. - a On Mon, Nov 17, 2008 at 8:10 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Indeed. Blobs is a great idea. We'll probably have to create further JSON extensions to support that. / Jonas Aaron Boodman wrote: +1, because I think it will be useful to pass other things to workers that JSON cannot represent (blobs) in the future. - a On Mon, Nov 17, 2008 at 8:03 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Hi All, Ben just wrote up a patch to support JSON objects as well as primitive values (0, null, false, etc) to be passed to and from workers using postMessage. Wanted to see what the reactions to this was. Is it a good idea or not? I seem to recall this coming up in the past in the original feedback about what features people wanted. The technical details are as follows: Any of the following values are passed by value as-is: * strings * numbers * booleans * undefined * null Anything else is passed to JSON.stringify (defined by Ecmascript drafts here[1]). If calling JSON.stringify throws the same error will be thrown by the function. Otherwise the message event fired on the other 'side' will contain the result of JSON.parse. / Jonas
Re: [whatwg] JSON support for worker postMessage
Yeah definitely.
You said: We'll probably have to create further JSON extensions to
support that.
My point is that there is no need to change JSON at all if we ever add
blobs to the list of supported types. Even if you happen to use JSON
internally for the implementation now, you could change it to use some
other serialization format in the future.
Basically, I don't think that just because you can pass a blob via
postMessage, that necessarily means you need to be able to serialize a
blob to JSON. Blobs might be very large, so it might not even make
sense to allow serializing them to JSON.
- a
On Mon, Nov 17, 2008 at 8:18 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Well, you'd probably want to support things like
w.postMessage({ command: do cool thing,
data: myBlob });
/ Jonas
Aaron Boodman wrote:
If you support worker.sendMessage(stuff), where stuff is defined
by convenience to be: whatever you are allowed to send
JSON.stringify(), then you could expand this in the future to also
allow blobs w/o changing anything about JSON.
- a
On Mon, Nov 17, 2008 at 8:10 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Indeed. Blobs is a great idea. We'll probably have to create further JSON
extensions to support that.
/ Jonas
Aaron Boodman wrote:
+1, because I think it will be useful to pass other things to workers
that JSON cannot represent (blobs) in the future.
- a
On Mon, Nov 17, 2008 at 8:03 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Hi All,
Ben just wrote up a patch to support JSON objects as well as primitive
values (0, null, false, etc) to be passed to and from workers using
postMessage.
Wanted to see what the reactions to this was. Is it a good idea or not?
I seem to recall this coming up in the past in the original feedback
about
what features people wanted.
The technical details are as follows:
Any of the following values are passed by value as-is:
* strings
* numbers
* booleans
* undefined
* null
Anything else is passed to JSON.stringify (defined by Ecmascript drafts
here[1]). If calling JSON.stringify throws the same error will be
thrown
by
the function. Otherwise the message event fired on the other 'side'
will
contain the result of JSON.parse.
/ Jonas
Re: [whatwg] Workers feedback
Ian, Thanks for taking the time to read and understand all the feedback. Although this is not my most preferred design for the API, I can live with it. I'm happy that we removed startConversation(). I think that was just extra complexity on top of an already large API. As for putting forward contradictory suggestions, I apologize for that. In the future, I will try to form final opinions before opining. Thanks, - a
Re: [whatwg] Workers feedback
On Thu, Nov 13, 2008 at 10:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Aaron Boodman wrote: On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? I think it's useful. Obviously it's not totally necessary. What are the use cases? Also note that we can't use it with shared workers since they can be connected to several pages from different uris. It represents the URI of the worker itself, not the URI of the calling page. In Gears, authors asked us for a location object because they had applications that could be served from different origins. Also in Gears, workers can be accessed across origins, so incoming messages need to be validated that they are from the correct origin. It's more convenient for a worker to access its own origin through an API the UA provides than to bake it into the script or send it in the first postMessage(). Although HTML5 workers don't have the ability to be accessed across origins, you do have the ability to receive ports that are connected to other origins, right? So this might still be an issue. Other than that, I can't think of any specific use cases. It seemed like a generally useful API to have access to. - a
Re: [whatwg] Sending MessagePorts after they have started
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 likely that the opening page gave you a URI to open and process. My expectation was that the base URI would always be the URI of the worker. I think of opening a worker a lot like starting a new process, or opening a new window. I would expect that the new process has its own base URI which is the same URI as the script it is running. - a
Re: [whatwg] Exposing UA information to workers
Jonas asked me about this in IRC, and specifically why I suggested
appCodeName (since everyone claims they are Mozilla). My thinking was:
a) Browser detection is a mess, scripts use everything on the
navigator object (often incorrectly) to try and figure out which
browser is which
b) HTML5 may eventually define something better
Therefore, I could see two rational things for workers to expose: all
of whatever window.navigator has today, or whatever the new better API
is that HTML5 defines. I guess doing some subset of what
window.navigator does today could also be rational, but I don't know
how to pick the subset.
FWIW, here is the browser detection code that many Google apps use:
http://code.google.com/p/doctype/wiki/ArticleUserAgent
It uses:
- userAgent
- product
- vendor
- platform
- a
On Mon, Nov 3, 2008 at 3:59 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
For future compat it would be good to expose to workers information on what
browser is currently being used. This can be used to work around bugs and
lack of features.
In a 'normal' window context the navigator object exposes a set of
properties, such as userAgent, that can be used for this purpose. I suggest
we add something similar to the worker context. The HTML5 spec defines the
following:
interface Navigator {
// client identification
readonly attribute DOMString appName;
readonly attribute DOMString appVersion;
readonly attribute DOMString platform;
readonly attribute DOMString userAgent;
// ... other things not related to identifying the UA
};
I'm not sure how stable this part of the HTML5 spec is, (I know firefox
exposes a whole host of more properties), but it seems like a good set to
start with. We should probably keep the two in sync if the window context
Navigator object changes in the future.
Orthoginally, it seems like at least the 'onLine' boolean on the Navigator
interface would be useful too, and could be exposed at the same place.
Let me know what you think.
/ Jonas
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
2008/11/13 Jonas Sicking [EMAIL PROTECTED]: So at this point the main problem with making any changes is that we are very close to shipping Firefox 3.1. I.e. it is extremely hard to make changes. It is very unfortunate that we have ended up in this situation again. We were in a very similar to the window.postMessage API where we had to scramble last minute to make changes, the result that time was that security issues in the API slipped by since those changes happened after we had done our security review of the spec. A few months ago representatives from google, apple, and mozilla met to try to agree to an API. We came up with a few guidelines, such as that it was ok to have a separate API for shared and dedicated workers as well as others that I don't specifically remember. At the end of the meeting we had a rough sketch of an API. A few days after that Hixie published a proposal. At mozilla we were largely fine with the proposal modulo some details that we commented on fairly quickly and then proceeded to implement. Now, months later, both google and apple is asking for some pretty significant changes, including reverting things like separate APIs for shared and dedicated workers. It is very close to release for us and we are already in a very frozen state, so making changes at this point is somewhere between risky and impossible. HIxie's draft after that meeting was August 20 (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015853.html), and my reply on this issue was Sep 12 (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016228.html). Not stellar turnaround, but not months either. In any case, I can definitely appreciate the timing is poor for Mozilla and apologize for that. If we really want to make changes to the spec, we better make them really fast, ideally within a day or two. And depending on the complexity of the changes we might still be able to do them. The other alternative is of course removing workers from FF 3.1 and waiting until next release (judging by past releases, somewhere between a year or two from now). Finally, we can simply stick with the current API, none of the complains about the current syntax seems to have been very catastrophic, such as doesn't satisfy use cases, hard to understand, easy to have hard-to-discover bugs, etc. They mostly seem to be syntactic and the case of the matter is as always that there is no perfect syntax as the problem is over constrained. This is true, the worst I can think of happening as a result of the API Mozilla is planning no shipping would be frustrating for developers or frustrating for implementors as more feature are added that don't fit well. I see lots of ideas floating around but many of them are severly lacking in detail so it's hard to comment on. Things like 'rename startConversation to connect' is very ambiguous as has shown by recent discussions. So what follows is an effort to try to focus in on some discussed changes more concretely: Thanks for restating the various proposals so well... The main two things that people seem to dislike in the current are 1. The many communication mechanisms. 2. Different APIs for shared and dedicated workers. I've said before that I don't really think 1 is true. There is currently one communication mechanism (postMessage/onmessage) and one connection mechanism (onconnect). There is also one convenience function on top of the communication mechanism (startConversaion), but is a stretch to call it a separate communication mechanism. The communication mechanism (postMessage/onmessage) does come in two flavors though as you for shared workers and dedicated workers call the functions on different objects. Ok, maybe 'mechanism' was not the right word, but there are still three separate ways to use the external API to workers (not counting passing a port as an argument). I think this is undesirable. Here are my preference on changes, in descending order: * Add a connect() method to Worker and/or SharedWorker There has been lots of talk about this, but I'm still confused as to what the exact proposals are due to lack of details. But here is my interpretation Details: - Make instantiating a SharedWorker *not* fire a 'connect' event automatically. - Remove the .port property from SharedWorker - Remove the postMessage/onmessage functions from Worker and DedicatedWorkerGlobalScope - Add a onconnect property on WorkerGlobalScope - Add a connect() method on AbstractWorker. The function fires a 'connect' even on the WorkerGlobalScope, the event has a .port property which is a MessagePort. This MessagePort is entangled with another MessagePort which is the value from the connect() function. Comments: Compared to just doing the other above proposals I think this adds needless complexion for value that I don't quite see. If you want to have several 'conversations', I.e. several separate
Re: [whatwg] Workers feedback
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? I think it's useful. Obviously it's not totally necessary. - a
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]: Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а): * Add startConversation() to SharedWorker, but rename it connect() and make the onconnect event fire inside the worker each time it is called. What event do you suggest to dispatch in the worker when connect() is called? I meant connect. The same connect event (I'm not sure of the constructor off the top of my head) that Hixie originally had being fired when new clients create new instances of a shared worker. From the above, it formally follows that a MessageEvent with name message is dispatched How does that follow? - a
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]: Well, that's what MessagePort.startConversation() sends, and the proposal only said that connect() is a renamed startConversation() from Worker (also, The postMessage() and startConversation() methods on Worker objects must act as if, when invoked, they immediately invoked the method of the same name on the port, with the same arguments). It doesn't make sense to me that startConversation() would dispatch a MessageEvent object with name message. If that's what the spec currently says, I think it should be changed. - a
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]: The startConversation(message) method is a convenience method that simplifies create a new MessageChannel and invokingpostMessage() with one of the new ports. - it doesn't do anything postMessage() couldn't do. Receivers are supposed to differentiate events by evt.data. I see. Well that kinda makes sense, as long as the method is not called 'connect'. It would be really silly if there were a 'connect()' method and an 'onconnect' event, but they were unrelated :). I feel that it probably is not productive to continue discussing details when there is disagreement on the large-scale shape of the API between myself, Jonas, and Hixie. My opinion on this detail, for example, probably varies depending on whether there is a startConversation() method on shared workers, dedicated workers, neither, or both. - a
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Jonas, Hixie, and I talked about this yesterday on IRC (logs start here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go into the next day). Jonas is still against removing postMessage/onmessage from the Worker interface in favor of connect() only. Also, several people feel like connect/startConversation is just a convenience and not totally necessary. In light of both of these, I have a new proposal for how to simplify/combine these two interfaces. Here are the deltas from the current spec: * Remove startConversation() from the Worker interface * Remove the port property from the SharedWorker interface and give it a postMessage and onmessage just like dedicated workers have. * Leave the interfaces for the insides of the workers as they are now There are other options for what to do with the inside interfaces. I would prefer that they were more normalized, but I already know that Jonas won't like that and I am fine with this proposal. Thoughts? - a
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
2008/11/4 Alexey Proskuryakov [EMAIL PROTECTED]:
Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а):
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function() { }
port.postMessage(ping);
// dedicated workers (inside)
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage(pong);
}
}
I think this can be written as (note the different name of MessageEvent
attribute, and the use of this in onmessage):
onconnect = function(e) {
e.messagePort.onmessage = function() {
this.postMessage(pong);
}
}
Right you are. Thanks for fixing.
Shared workers are exactly the same except the constructor is
SharedWorker(foo.js, foo);
Is there any benefit in having a different name for this constructor? If
dedicated and shared workers are going to have identical implementation
(notably, if they have exactly the same lifetime), I don't see any benefit
in making them look different.
I don't have a strong opinion on this either way.
- a
[whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Hello all,
A few months ago, I suggested that we combine the DedicatedWorker and
SharedWorker interfaces
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016228.html),
but we never reached consensus.
Since Mozilla and Apple are both working on implementing this now, I'd
like to revisit the issue before we end up with something non-ideal
baked into implementations.
My biggest issue with the proposal as currently drafted is that there
are so many different ways to send and receive messages. I think this
overcomplicates the proposal for both developers and implementors.
For dedicated workers, you can either send single messages using the
Worker object directly, like in Gears:
var worker = new Worker(foo.js);
worker.postMessage(ping);
Or, you can use the more powerful startConversation() API to easily
group related messages together:
var port = worker.startConversation();
port.postMessage(ping);
Note that the worker has to know ahead of time which API the callers
will use since the way that it replies is different depending on that.
If the caller used Worker.sendMessage(), the worker should reply like
this:
onmessage = function() {
postMessage(pong);
}
... but if the caller used Worker.startConversation().sendMessage(),
then the worker should reply like this:
onmessage = function(e) {
e.port.postMesage(pong);
}
SharedWorkers require a third, completely different API to send messages:
var w = new SharedWorker(foo.js, foo);
w.port.postMessage(ping);
w.port.onmessage = function(e) {};
The interface to receive messages in a SharedWorker is also special:
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage(pong);
}
}
This lack of generality bothers me on an aesthetic level, but I also
think it has the following real problems:
* Workers have to know what interface was used to send them messages.
If the page using a worker decide to start using a more powerful send
API, the worker must also be upgraded. You can already see examples of
this problem in the samples at the beginning of the draft. They are
marked with the comments // support being used as a shared worker as
well as a dedicated worker.
* Having different interfaces for each use case means that each new
feature has to be added to each interface separately. We can already
see this problem in the fact that the SharedWorker interface lacks
startConversation() for no apparent reason.
* Having multiple interfaces probably increases the chance of
developers misunderstanding and using the wrong tool for the job. I
can easily see developers accidentally reimplementing
startConversation() on top of Worker.sendMessage().
* More API for developers to learn and implementors to build.
I think that these issues can all be addressed by simplifying and
combining the various APIs. This will make the simplest examples of
workers require slightly more code, but I think it is much simpler and
more elegant.
Here is how it would work:
* Get rid of the DedicatedWorker interface.
* Add startConversation() to SharedWorker, but rename it connect()
and make the onconnect event fire inside the worker each time it is
called.
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function() { }
port.postMessage(ping);
// dedicated workers (inside)
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage(pong);
}
}
Shared workers are exactly the same except the constructor is
SharedWorker(foo.js, foo);
Note that I do not think it is necessary to implement this all at
once. For one, the SharedWorker constructor could easily be punted for
future releases.
Thoughts?
- a
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
On Mon, Nov 3, 2008 at 11:08 PM, Aaron Boodman [EMAIL PROTECTED] wrote: sendMessage() I'm sorry, please excuse my mixing the names 'sendMessage' and 'postMessage'. The Gears API is named 'sendMessage' and I keep accidentally using that. The name in Web Workers should of course be 'postMessage' everywhere. - a
Re: [whatwg] Placeholder option for text input boxes
2008/10/1 Kristof Zelechovski [EMAIL PROTECTED]: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288 contains the same deprecating statement. I think it would be really unfortunate if we followed through with this, and I definitely think that input.placeholder should work. The attribute/property symmetry is one of the longest running traditions in web development, and makes programming the DOM with javascript much more pleasant. We shouldn't break with long-established, useful traditions just to make a small minority of cases more consistent. - a
Re: [whatwg] Placeholder option for text input boxes
On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Please. This thread is not abort how to write JavaScript code in general. It is about how to write the feature detection code. This kind of code should be especially robust and relying on deprecated features does not make it more so. Ok, let's separate out the 'how people should program' part from the 'what we will support part'. My opinion is that input.placeholder should be supported, because it is consistent with how everything else works. I don't think that most web developers even know that accessing attributes as properties is deprecated, and would be surprised that setting input.placeholder does nothing. - a
Re: [whatwg] workers
2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED]: I'm not sure it's so good in the case of dedicated workers either, as they can be used from other contexts via additional message ports. The close() method could just close the default port. Sure, but in order for that to have happened, whoever created the worker in the first place must have done it on purpose. The original worker instance is anonymous. If the creator of that worker decides to share it, that's fine, but it's more like cooperative sharing. close() was added so that you could forcibly kill a worker. For example, if you are searching a large set with many workers, you may want to kill them once one finds a match. The same could be achieved by just setting all the ports to null and waiting for GC, but: a) GC might not be for awhile, which is wasteful b) It is hard to track where all the ports went So I think it is useful to have a conceptual difference between workers that are 'dedicated' and those that are 'shared'. - a
Re: [whatwg] workers
2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED]: Hmm... So this is more about how you use the interface, not what the object behind it is. If one chooses to never call close() on a shared worker (or, say, sets myWorker.close to null right after invoking constructor), it becomes indistinguishable from a dedicated worker. Hiding close() possibly sounds more like something a high-level framework may want to do to enforce a certain design pattern than a core feature. I could see that too. When all the parties accessing a shared worker are from the same origin (as they are today) it is less of an issue. You can probably assume that they know not to close() the worker. Do you have any thoughts on the extra API on dedicated workers proposed by Jonas (DedicatedWorker::sendMessage, DedicatedWorkerGlobalScope::onmessage)? - a
Re: [whatwg] workers
On Wed, Sep 24, 2008 at 6:26 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Sorry about the slow feedback, has been on vacation most of the time. np. So first off I don't think we can remove the ability to pass MessagePorts around. This ability exists in Window.postMessage already per spec so nothing that the workers spec does can change that. Also, if we think the pass-around-ability of ports affect how much we want to use them, punting the pass-around-ability to the second version of the spec shouldn't really affect how we design the API as we'll arrive at the second version sooner or later. I'm thinking of MessageChannels, MessagePorts, and Workers as one new task for implementors, since as far as I know, nobody has shipped any of these yet. So given that, I prefer the current API. I think that for the common case of non-shared workers it makes for a simpler API. The fact that you argue that there should be a catch-all global onmessage inside the worker seems to indicate that using onconnect is lacking somewhere. I agree with the benefit of keeping shared vs. non-shared workers as similar as possible. However I feel that the complexities that come with always using ports for non-shared workers outweighs it. In the current design, there are three separate mechanisms to connect to and communicate with a worker: a) DedicatedWorker::sendMessage() + DedicatedWorkerGlobalScope::onmessage b) DedicatedWorker::startConversation() + DedicatedWorkerGlobalScope::onmessage c) new SharedWorker() + SharedWorkerGlobalScope::onconnect I would like to combine all of these into one common mechanism: - Create a worker using either new Worker() or new SharedWorker() - Call connect() to get a channel - Inside the worker, listen for onconnect, then receive messages using the port's onmessage event This consolidates all the use cases into one common mechanism. It is true that it makes it a little extra work for the very simplest use cases. But I think that 'conversations' are important enough to warrant making them the only way to communicate with workers. - a
Re: [whatwg] workers
On Wed, Sep 24, 2008 at 8:27 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
In the current design, there are three separate mechanisms to connect
to and communicate with a worker:
a) DedicatedWorker::sendMessage() + DedicatedWorkerGlobalScope::onmessage
b) DedicatedWorker::startConversation() +
DedicatedWorkerGlobalScope::onmessage
c) new SharedWorker() + SharedWorkerGlobalScope::onconnect
I would like to combine all of these into one common mechanism:
I spoke with Jonas on IRC today:
http://krijnhoetmer.nl/irc-logs/whatwg/20080924#l-379
Though I failed to convince him that we should simplify all these down
to just one mechanism, but he did support combining b) and c) with
something like (my proposal - global onmessage) +
DedicatedWorker::sendMessage + DedicatedWorkerGlobalScope::onmessage.
That would look like this:
OUTSIDE
interface MessagePort {
EventListener onmessage;
EventListener onclose;
void sendMessage(String message);
}
interface Worker {
EventListener onload; // informative only, you can sendMessage
before this happens
EventListener onerror; // only load errors, not script errors at runtime
Port connect();
};
interface DedicatedWorker : Worker {
void close();
void sendMessage(String message);
};
INSIDE
interface WorkerContext {
EventListener onclose;
EventListener onconnect; // fired each time connect() is called on a
corresponding Worker object
readonly String name;
void close();
// + all the utils stuffs
};
interface DedicatedWorkerContext : WorkerContext {
EventListener onmessage; // fires when someone calls
DedicatedWorker::sendMessage()
};
EXAMPLE SIMPLE USAGE
// outer
var worker = new Worker(foo.js);
worker.onmessage = function(e) {
alert(e.message);
}
worker.sendMessage(hi!);
// inner
self.onmessage = function(e) {
self.sendMessage(bye);
}
EXAMPLE LESS SIMPLE USAGE
// outer
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function(e) {
alert(e.message);
}
port.sendMessage(hi!);
// inner
self.onconnect = function(e) {
e.port.onmessage = function() {
e.port.sendMessage(bye);
}
}
- a
Re: [whatwg] workers
Ping? Thoughts? Anyone? Jonas, I know you are the one most likely to be affected by this in the near term. Thoughts? I know you are generally in favor of something close to the current Gears API, and generally against the concept of MessagePorts. But I think introducing a MessagePort object is important for two main reasons: - Makes the interface very similar for dedicated and shared workers, which I think makes it easier to use both. - Makes it easy for developers to set up multiple 'conversations' (ports) between clients and workers by calling connect(). The lack of this is a key annoyance with current Gears workers Note that I have suggested punting on passing ports around initially, which I feel like is the harder part. On Mon, Sep 15, 2008 at 4:52 PM, Chris Prince [EMAIL PROTECTED] wrote: I think your proposal nearly works for window.postMessage() too. If you move 'onconnect' and 'connect()' into a MessageReceiver interface [better name TBD], and make Worker and Window both inherit from MessageReceiver, do you end up with a unified messaging model? Maybe. One wrinkle is that Window's postMessage is a little different, because you have to pass the origin you're targeting (http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting). I do think that the 'conversation' concept that MessagePorts represent is also useful for cross-window communication and it would nice to generalize these as much as possible. - a
Re: [whatwg] workers
Thinking about this some more, having the port convenience
properties gets confusing when there are multiple clients sending
messages, and doesn't make a whole lot of sense with shared workers.
I think we should just get rid of these. It only adds one line of code
to the simple case. Also, I forgot 'onerror' in my last IDL proposal.
So here's an update:
OUTSIDE
interface MessagePort {
EventListener onmessage;
EventListener onclose;
void sendMessage(String message);
}
interface Worker {
EventListener onload; // informative only, you can sendMessage
before this happens
EventListener onerror; // only load errors, not script errors at runtime
Port connect();
};
interface DedicatedWorker : Worker {
void close();
};
INSIDE
interface WorkerContext {
EventListener onclose;
EventListener onmessage; // convenience -- receives all messages
sent to ports in this worker
EventListener onconnect; // fired each time connect() is called on
a corresponding Worker object
readonly String name;
void close();
// + all the utils stuffs
};
EXAMPLE USAGE
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function(e) {
alert(worker says: + e.message);
}
port.sendMessage(hi!);
// foo.js
self.onconnect = function(e) {
e.port.onmessage = function() {
e.port.sendMessage(bye);
}
}
// foo.js (alternate implementation)
self.onmessage = function(e) {
e.port.sendMessage(bye);
}
- a
[whatwg] workers
I've reviewed and digested the latest workers update
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015853.html).
I think we're converging :).
There are still a few improvements and simplifications I'd like to
see, however. With these (relatively minor) changes, I'd be really
happy with what we have.
* I think it was an interesting idea to have separate interfaces for
Dedicated and Shared workers, but in the end I don't think there's
enough difference between the two cases to justify it. I'd rather have
the total API surface be smaller, and generalize concepts as much as
possible. So...
- We should remove all the sendMessage/onmessage stuff from
DedicatedWorker, and just use the port convenience property.
- We should move onconnect() up into WorkerGlobalScope
* Similarly, I'd like to rename startConversation() to connect(). I
think this aligns nicely with the onconnect event (connect() should
also trigger a 'connect' event inside the worker).
* I think it would be a nice convenience to have an onmessage event
inside workers that receives all messages sent to any port in the
worker.
* We have discussed having onerror expose runtime script errors that
happened inside the worker. I don't think this makes sense for shared
workers, so I propose that it be spec'd to only expose load errors.
Script errors can still be exposed via a global onerror property
inside the worker, and they can still be reported to the error
console. I don't think having script errors that happened inside a
worker be exposed outside it is that useful (load errors are useful,
though).
* I think onclose makes sense on Port instead of on Worker. The other
side of a Port can close out from under you, even if it is a window.
* Ojan brought this up earlier, but I don't think there should be
anything added to the global scope of workers except a single 'self'
object, which implements all the APIs that are available there.
* I still don't buy the utility of passing around MessagePorts, so I
suggest we table that for v2. It can always be added back later.
Here is an IDL sketch of what the API would look like after these changes...
OUTSIDE
interface MessagePort {
EventListener onmessage;
EventListener onclose; // if the other side goes away
void sendMessage(in DOMString message);
}
interface Worker {
EventListener onload;
Port port; // convenience -- corresponds to the port available on
the created worker's WorkerContext object
Port connect(); // the method previously known as startConversation
}
interface DedicatedWorker : Worker {
void close();
}
INSIDE
// this is all exposed via self
interface WorkerContext {
EventListener onclose;
EventListener onmessage; // convenience -- receives all messages
sent to this worker, from any port
// fired when the worker is first created, and for each additional
new SharedWorker() or connect() call
EventListener onconnect;
readonly String name;
readonly MessagePort port; // convenience -- corresponds to the port
available on created Worker object
void close();
// + all the utils stuffs
}
CREATING WORKERS
var worker = new Worker(url);
var sharedWorker = new SharedWorker(name, url);
Let me know what you think!
- a
Re: [whatwg] A slightly different use-case for shared workers
On Thu, Aug 28, 2008 at 3:11 PM, Jonas Sicking [EMAIL PROTECTED] wrote: I think that example could be solved simpler actually. An audio element can be moved between two documents without requiring any interference in its functionality. So if pandora used an audio to play music they could easily transfer the playing to another window. Yup, Roc already schooled me. - a
[whatwg] A slightly different use-case for shared workers
I encounter sites frequently that want to pop out part of their application free of the page, into a smaller window. For example, Pandora radio (http://pandora.com) does this. The player starts out embedded in the normal content area, but users have the option to pop it out into a smaller, separate window. One problem with these apps is that they have to shutdown and restart in the popup window. So if I'm playing a song in Pandora, it loses tracks of where I am and restarts in the pop out player. It seems like shared workers could help with this problem. If some future version of workers had access to the Audio API, the base pandora.com page would start a shared worker, which would be used to play the audio. If the user opted to open the player in a popup, the popup would simply obtain a reference to the existing worker. The music wouldn't have to restart. If the user navigated away from pandora.com, the popup would keep the worker alive until it was closed. - a
Re: [whatwg] A slightly different use-case for shared workers
On Wed, Aug 27, 2008 at 5:23 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 9:59 AM, Aaron Boodman [EMAIL PROTECTED] wrote: I encounter sites frequently that want to pop out part of their application free of the page, into a smaller window. For example, Pandora radio (http://pandora.com) does this. The player starts out embedded in the normal content area, but users have the option to pop it out into a smaller, separate window. One problem with these apps is that they have to shutdown and restart in the popup window. So if I'm playing a song in Pandora, it loses tracks of where I am and restarts in the pop out player. It seems like shared workers could help with this problem. If some future version of workers had access to the Audio API, the base pandora.com page would start a shared worker, which would be used to play the audio. If the user opted to open the player in a popup, the popup would simply obtain a reference to the existing worker. The music wouldn't have to restart. If the user navigated away from pandora.com, the popup would keep the worker alive until it was closed. Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Hm, that is a good point. I didn't consider the the audio object would keep playing smoothly when moved between documents. That seems unlikely to be reliable across implementations, but I'll keep my fingers crossed :). - a
Re: [whatwg] A slightly different use-case for shared workers
On Wed, Aug 27, 2008 at 6:46 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: Works on Firefox trunk :-). Testcase attached. (The Vorbis file takes a while to download so you should probably let it play through once before trying the test.) What is the rationale behind having to call play() again? Also, should it also work if you just pass a reference to the node into the other window? - a
Re: [whatwg] WebWorkers vs. Threads
On Wed, Aug 13, 2008 at 11:50 AM, Shannon [EMAIL PROTECTED] wrote:
The WebWorkers implementation (scary! hide your children!!):
--- worker.js ---
updateGlobalLa = function (e) {
var localLa = someLongRunningFunction( e );
workerGlobalScope.port.postMessage(set la = + localLa);
}
workerGlobalScope.port.AddEventListener(onmessage, updateGlobalLa, false);
workerGlobalScope.port.postMessage(get la);
--- main.js ---
// global object or variable
var la = 0;
handleMessage = function(e) {
if (typeof e.match(set la))
la = parseInt(e.substr(3));
} else if (typeof e.match(get la)) {
worker.postMessage(la.toString());
}
}
var worker = new Worker(worker.js);
worker.AddEventListener(onmessage, handleMessage, false);
Unlike the one-line example above we increment the global value based on
some long-running calculation on its original value (rather than just add
1). This shows a more realistic use case for threading. Unfortunately our
potentially dangerous one-liner is now an equally dangerous 18-line monster
spread over 2 files and we STILL haven't solved the issue of another worker
or the main context updating 'la' between our original postMessage query and
our response.
You're right that if you try to use workers like threads, you end up
with threads. A more message-passing style implementation is easier.
In particular you would not want to allow the worker to 'get' and
'set' individual variables, but pass it messages about work you would
like it to perform, and have it pass back messages about the result.
This is less flexible than threading but easier to reason about.
// main.js
var la = 0; // what is with this variable name?
var worker = createWorker(worker.js);
worker.port.addEventListener(message, function(e) {
la = parseInt(e.message);
alert(la);
}, false);
// worker.js
workerGlobalScope.port.addEventListener(message, function(e) {
workerGlobalScope.port.sendMessage(someLongRunningFunction(parseInt(e.message)));
}, false);
A more realistic example would have the worker also doing synchronous
IO between chunks of longRunningFunctions, and then finally passing a
result back to the UI.
I should also point out that even this simple, naive and probably incorrect
example still took me nearly 2 hours to write - largely due to the
complexity of the WebWorkers spec and the lack of any decent examples.
Honestly anyone who thinks this interface is supposed to make things easier
is kidding themselves.
In my experience with Gears, it has not been difficult for people to
get started with workers. Many programmers are already familiar with
message passing style concurrency, so it is easy for them to pick up
workers. But even when they don't, they are conceptually simple.
I'm not sure what happened in your case. It is true that the spec is
not written as a tutorial for developers, but as a rulebook for
implementors, and this makes it hard to grok for new developers. That
may have contributed.
There are a bunch of examples that Ian has kindly written at the very
top of the document. What was unhelpful about them?
Regardless of the kind of Getters/Setters/Managers/Whatever paradigm you use
in your main thread you can never escape the possibility that 2 workers
might want exclusive access to an essential global object (ie, DOM node or
global setting). So far I have not found any real-world programming language
or hardware that can do this without some kind of side-effect or programming
construct (ie, locks, mutexes, semaphores, etc...). What WebWorkers is
really doing is requiring the author to write their own.
You are thinking about this wrong. Don't try to give two chunks of
your program concurrent access to shared state; that is impossible.
Instead realize there is no shared state and factor your program into
two pieces -- one to do the heavy lifting and one to manipulate the
UI. Then create a protocol for them to communicate with message
passing.
I don't think I can stress enough how many important properties and
functions of a web page are ONLY available as globals. DOM nodes, style
properties, event handlers, window.status ... the list goes on. These can't
be duplicated because they are properties of the page all workers are
sharing. Without direct access to these the only useful thing a worker can
do is computation or more precisely string parsing and maths.
You're forgetting the ability to do synchronous IO and the ability to
share workers between pages. Both of these benefits have been
explained in previous messages.
At this point I suspect we will have to agree to disagree. Perhaps
keep an eye on the spec as it continues to evolve. Perhaps it will
start to grow on you.
- a
Re: [whatwg] WebWorker questions
On Tue, Aug 12, 2008 at 4:50 AM, Shannon [EMAIL PROTECTED] wrote: If a WebWorker object is assigned to local variable inside a complex script then it cannot be seen or stopped by the calling page. Should the specification offer document.workers or getAllWorkers() as a means to iterate over all workers regardless of where they were created? I don't follow the first phrase here, but I can still answer the overall quetsion... There is currently no API to stop a worker from the outside, only from the inside. Providing an API to kill a worker from the outside is a little weird because we also want to be able to share workers between multiple pages. If we did both of these things then one page could kill a worker that other pages are relying on. Not saying this is unreasonable, just something to think about. As for getAllWorkers(), yes, I think this would be cool (perhaps for a future version of the API). If for no other reason than that there are interesting applications for diagnostics and introspection. Is it wise to give a web application more processing power than a single CPU core (or HT thread) can provide? What stops a web page hogging ALL cores (deliberately or not) and leaving no resources for the UI mouse or key actions required to close the page? (This is not a contrived example, I have seen both Internet Explorer on Win32 and Flash on Linux consume 100% CPU on several occasions). I know it's a vendor issue but should the spec at least recommend UAs leave the last CPU/core free for OS tasks? You are right that workers and other things that are controllable by authors but use threads should be pooled and limited. It shouldn't be possible to DOS a browser using workers. Currently, Gears doesn't do this, but we definitely should. I agree the spec should have a warning to this effect. Can anybody point me to an existing Javascript-based web service that needs more client processing power than a single P4 core? It's easy to imagine examples, but of course none exist today since this capability doesn't exist in browsers. 100ms is generally considered to be absolute maximum amount of time a UI can take to update after direct interaction. After that, users think it is hung. It's not that hard to imagine applications for JS computation which surpass this amount of time, particularly when you consider that the cpu(s) might be busy doing something else! But I think that computation is the least interesting of the benefits that workers provide. The others ones are: a) Workers allow applications to perform blocking IO. Currently this isn't possible because it would block the UI too. In the current database proposal, every single SQL statement is asynchronous. b) Workers allow you to share parts of your application between windows. So for example, if you open Google Docs in two windows, they can't share any code today. Google docs is a pretty significant JS app, so this is already crazy inefficient. But if the user has Google Docs Offline enabled, then both copies of the app are also both trying to synchronize to the same local database. The only way to get around this is to implement a watchdog system where each window tries to detect each other through updates to the shared database. Shared workers allow you to solve this in a more natural way. Just put the synchronization code in a shared worker. All the instances of the app can access it. Shouldn't an application that requires so much grunt really be written in Java or C as an applet, plug-in or standalone application? No. Web applications have many benefits over native apps. We should try to increase the number of apps that can be written on the web. If an application did require that much computation isn't it also likely to need a more efficient inter-thread messaging protocol than passing Unicode strings through MessagePorts? At the very least wouldn't it usually require the passing of binary data, complex objects or arrays between workers without the additional overhead of a string encode/decode? We (Google) have proposed the addition of being able to pass complex JS objects without manually encoding/decoding, and I think that this will be added eventually. But even with just strings passing, it is easy to imagine applications where there is a large amount of background work that needs to be done given a small amount of input. For example, download all the documents for user X and store them in the database. Is the resistance to adding threads to Javascript an issue with the language itself, or a matter of current interpreters being non-threadsafe? Threads as they exist in java and c are widely understood to be difficult: http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/toc=comp/mags/co/2006/05/r5toc.xmlDOI=10.1109/MC.2006.180 I don't have a problem with coroutines personally, but I think that there is still a place for full processes in any programming environment. Sometimes it's just
Re: [whatwg] WebWorker questions
On Tue, Aug 12, 2008 at 8:24 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: A very interesting post, too bad nobody from Google bothered to give an exhaustive reply. Just a couple of thoughts below. Just as an FYI, most of the Gears team is located in Mountain View which is PST. This message was sent at 4:50 AM for us, and as we are programmers, the first of us saw it approx 5 hours later :). - a
Re: [whatwg] WebWorkers vs. Threads
On Sun, Aug 10, 2008 at 5:54 PM, Shannon [EMAIL PROTECTED] wrote: * each coroutine gets a real OS thread (if available). snip Coroutines in Lua are not operating system threads or processes. Coroutines are blocks of Lua code which are created within Lua, and have their own flow of control like threads. Only one coroutine ever runs at a time, and it runs until it activates another coroutine, or yields (returns to the coroutine that invoked it). Coroutines are a way to express multiple cooperating threads of control in a convenient and natural way, but do not execute in parallel, and thus gain no performance benefit from multiple CPU's. However, since coroutines switch much faster than operating system threads and do not typically require complex and sometimes expensive locking mechanisms, using coroutines is typically faster than the equivalent program using full OS threads. /snip --http://lua-users.org/wiki/CoroutinesTutorial Is this description incorrect? It seems at odds with what you said about Lua coroutines getting an OS thread (if one is available). - a
[whatwg] Offline Web Applications feedback
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 quickly turn into a mess as we add additional fields and rows. - I like the fallback entry feature, but I don't understand why it is coupled to opportunistic caching. On the Gears team, we frequently get requests to add a feature where a certain pattern of URLs will try to go the network first, and if that fails, will fall through to a certain cached fallback URL. But nobody has asked for a way to lazily cache URLs matching a certain pattern. Even if they had, I don't understand what that has to do with the fallback behavior. Can we split these apart, and maybe just remove the opportunistic caching thing entirely? - It seems odd that you request a resource and the server returns 400 (bad request) we fallback. Maybe it should just be up to the server to return an error message that directs the user to the fallback URL? I'm not sure about this one, looking for feedback. - Maybe this is obvious, but it's not specified what happens when the server returns a redirect for a resource that is being cached. Do we cache the redirect chain and replay it? - In practice, I expect the number of URLs in the online whitelist is going to be unbounded because of querystrings. I think if this is going to exist, it has to be a pattern. - 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 space of URLs they expect to be online as well as the ones they expect to be offline. But maybe we should just remove the whole thing about failing loads of resources not in the manifest and online whitelist for v1. - a
Re: [whatwg] Offline Web Applications feedback
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 quickly turn into a mess as we add additional fields and rows. We've implemented the current format already in WebKit (available in nightlies and the Safari 4 Developer Preview). The format does not seem to have much call for extension and seems easy to understand and use as-is. I think that the unnamed columns make it difficult to use, because you have to remember which column does what. I've used a similar text-based format, the Firefox chrome.manifest format, and I found it difficult for the same reason. If we ever needed to have columns that were optional for a given section, it would become difficult to see if they were specified because of the lack of names. If rows ever get long with more than a few columns, there is no ability to wrap them with the given format. This would come for free with many other formats. If we ever needed to add any kind of hierarchy, we would have to reinvent something like XML, JSON, or YAML. To me, the idea of inventing a custom one-off format for this is ugly. I realize this is somewhat a matter of taste (unix uses lots of line-based format and hey, it works fine for them), so I will drop this and just leave it as a vote for XML. - I like the fallback entry feature, but I don't understand why it is coupled to opportunistic caching. On the Gears team, we frequently get requests to add a feature where a certain pattern of URLs will try to go the network first, and if that fails, will fall through to a certain cached fallback URL. But nobody has asked for a way to lazily cache URLs matching a certain pattern. Even if they had, I don't understand what that has to do with the fallback behavior. Can we split these apart, and maybe just remove the opportunistic caching thing entirely? I think the idea of opportunistic caching (as I understand it) is that the author can be lazy, and not write a manifest at all. Ok, I don't think this feature needs to be in this spec then, IMO. HTTP caching essentially does the same thing, anyway. If it is in the spec, I think it should be separated from the fallback feature. - a
Re: [whatwg] Workers feedback
On Wed, Aug 6, 2008 at 4:24 AM, Ian Hickson [EMAIL PROTECTED] wrote: * I've written an intro section which shows how the API is expected to be used. I've tried to illustrate each use case that people raised. I will add more tomorrow. Thanks, that helps a lot. * I've moved APIs to a utils object, so that we rarely, if ever, have to add members to the global scope (reduces chances of future collisions). I am opposed to the utils object. I don't see any precedent for this anywhere, and it just feels ugly to me. I liked it the way you had it before, with these APIs in a shared base interface. * I've replaced the URL string with a Location object. Thanks :). I've tried to simplify the MessagePort interface as follows: * messages are now queued, and won't be delivered until either the 'start()' method on the port is called, or the 'onmessage' attribute is set to some value. * messages are now queued, instead of a port becoming inactive when its other side is suspended. Can you explain the rationale for these two changes? * I've made the worker receive its first port as a property of the global object (port) instead of having to listen to the 'connect' event (though the connect event still fires, so you can do shared workers). I liked it the way you had it, before. I'd rather the first connection to a worker wasn't a special case, either for the worker or for the worker's creator. That's also one reason why I like having a separate Worker object and having the two-step process of creating the worker, then sending it a message. It means that creating a new channel to a worker is always the same. On Mon, 4 Aug 2008, Aaron Boodman wrote: So for example, I would be for moving over a subset of the navigator and location objects as-is (these seem to work well), but against moving over the document.cookie interface (it works poorly). I agree with porting some subset of 'navigator' over, though since the relevant parts of 'navigator' aren't defined even for HTML5 yet, I haven't yet done this. There's an issue marker in the spec about this. What bits would you like defined? The ones that are most often used for browser detection are most important, so: - appName - appCodeName - appVersion - platform - userAgent I know the whole business of browser detection is a big mess right now, so if you're working on defining something better, I'd be open to having some combination of the old navigator object and that new thing in workers. But there is a lot of code that is very carefully crafted to analyze the navigator object, so maybe it's best not to mess with that too much. On Tue, 5 Aug 2008, Aaron Boodman wrote: - It seems like we might want an object that represents workers. This would allow us put the 'onload' and 'onerror' events from MessagePort there, instead of on MessagePort, which makes more sense to me (I don't know what it means for a MessagePort to 'load' or 'error' outside of the context of a worker). The main reason for not having a separate Worker object is that I couldn't find anything that would go on it other than the port. You'd still want the unload messages going to whoever owns the port, not whoever created the worker, if you passed the port around. Basically, adding a Worker object just seemed like it would double the number of objects, and potentially the complexity if we also allow Worker objects to be sent along channels, without really providing any new features. I think that 'load', 'error', and 'unload' could go on the worker. As far as I can tell, the only thing 'load' and 'error' are used for is telling the creator of a worker that the worker loaded or failed to load. In that case, it seems wrong to throw them on MessagePort, since MessagePorts are also used for many other things. I also still think that Workers could have their own sendMessage. The messages sent to this would be delivered to the worker as 'message' events targeted at WorkerGlobalObject (eliminating the need for onconnect?). This would make Workers and postMessage very similar to Window and postMessage, which seems nice to me. MessagePort.onunload could then change to 'onclose' to go with the close() method. The main reason I used 'unload' and 'close' is consistency with how the rest of the platform works. (With a Window, you call window.close() to invoke window.onunload.) I can change that if people want, though I do think consistency is worth keeping here. I think the concept of a port becoming inactive is interesting in all the cases MessagePorts are used, so this should stay. In fact, should it be called 'oninactive'? I would prefer to see something like: void Worker.postMessage(DOMString message) void Worker.postMessage(DOMString message, MessagePort port) That way the way to establish a new channel is the same for all callers. It also has the advantage of looking similar to a window's postMessage API. With the exception
Re: [whatwg] Offline Web Applications feedback
On Wed, Aug 6, 2008 at 7:08 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: HTTP caching can't promise that all the resources you load when your Web App loads will be available offline. But neither can this feature, since a resource is only there if the application previously loaded it for some reason. - a
Re: [whatwg] Offline Web Applications feedback
On Wed, Aug 6, 2008 at 7:49 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Right, the idea is that you just have your whole web app as an opportunistic caching namespace and make sure it loads everything it ever needs offline the first time it loads. I don't think this is a great feature but I believe this was the design intent/ I see, thanks. - a
Re: [whatwg] Workers comments
On Mon, Aug 4, 2008 at 8:24 PM, Jonas Sicking [EMAIL PROTECTED] wrote: The overall concern is that I think the spec is unnecessarily complicated. I'll comment in detail below on specific features. An overall requirement for mozilla is that we are very selective about which features are exposed on the thread. For example exposing a full navigator or window object is a huge amount of work. This doesn't mean that it shouldn't be done, but there needs to be very good reasons when exposing things. I don't see anything about a 'navigator' object except this comment: May need to define a browser sniffing API (like window.navigator). That doesn't imply to me that it will be the entire navigator object, just something having similar capabilities wrt browser sniffing. Similarly, the only thing that the spec says should be available from Window are the things listed in these two interfaces: http://www.whatwg.org/specs/web-workers/current-work/#the-windowworker http://www.whatwg.org/specs/web-apps/current-work/#window This is a very small subset of Window. So the first comment is the 'window' and 'self' properties. I agree, these seem unnecessary. On the subject of window. I think the fact that the global scope interface is named something with 'Window' is very confusing for anyone reading the spec. While I agree that there is some amount of association between the global scope and the window, I think there is a much stronger association between window and the properties that live on it, such as window.location, window.document, window.frames, window.scrollX, etc. I agree with this. I think the global object in a worker should be called something different, such as WorkerGlobal or WorkerContext. I don't think we should pay too much attention to trying to make existing code compatible with this environment, as that seems hopeless. However, I do feel that in the cases where an existing interface works nicely for its intended purpose, there's no point reinventing it. Less brain print, as a coworker likes to say. So for example, I would be for moving over a subset of the navigator and location objects as-is (these seem to work well), but against moving over the document.cookie interface (it works poorly). Additionally I am worried that sharing interfaces between the global scope object for browser contexts, and the global scope object for workers is going to lead to unnecessary feature creep with argument such as the object is available in the browsing context, so why not make it available in the worker context. I much rather want arguments like this feature is needed in thread contexts because of reason X and use case Y. I don't think having a common base interface in the spec is going to make this kind of feature creep any more or less likely. It just seems natural that if functionality is available in both workers and the main browsing context, it should work the same way. What is the use cases for the onconnect and onunload properties? 'onconnect' doesn't seem to add anything beyond simply leaving the code outside any function. I.e. doing I believe that onconnect is meant to be how a worker gets the MessagePort object from people who are trying to talk to it. Hixie, it occurs to me that it might be helpful for everyone if you could add some code samples for how applications would use this API to the top. It's easier to grok what the point is at a glance, and allows people to think about the API proposal holistically instead of trying to piece it together from the algorithms. The fact that the only way to communicate between workers and the main browser context is through MessagePorts seems unnecessarily complex as well as differing from how windows communicates using postMessage. I think MessagePorts are a fine concept, but I don't think they should be mandatory as I think in many cases they are more complicated than needed. The whole concept of entangled message ports that clone and die when you pass them around is something that I don't think we should force upon developers unless absolutely needed. In the current draft I can't even see how to reach the message port object inside the worker, though that might be a temporary oversight. But it does indicate that the level of complexity for communication is non-trivial. A better model seems to be reusing what we do for window objects. Simply make createWorker return a Worker object that has a sole .postMessage property, and make it possible to pass a Worker object through postMessage. We would also have to expose some way to send messages to the main browsing context, either through a separate postMessageToWindow function inside the worker context, or through a Worker object representing the main browser context. This doesn't stop us from adding support for MessagePorts as well, but it allows sites not to mess with them unless needed. I can get behind simplifying the API. However, the simple I would go
Re: [whatwg] Methods defined for one document called after that document is no longer the one being displayed
On Tue, Aug 5, 2008 at 1:12 AM, Ian Hickson [EMAIL PROTECTED] wrote:
Right now, if you navigate an iframe to a document, and take a
reference to a method defined in that document, and then navigate that
iframe to another document, and then call the method, browsers differ in
what they do.
By 'method' do you mean any function object, defined anywhere in that
window? For example, does document.getElementById count? Does the foo
in var myglobal = {foo:function(){...}}; ? What about getters?
- In one browser, the method call fails, saying that methods can't be
called while the document that defined them isn't the active document
of the browsing context whose global object is the method's.
Off the cuff, this behavior seems good to me. I think it would be good
if this applied to any function or getter.
- a
[whatwg] Web Workers and MessagePort feedback
I'm still digesting the Web Worker proposal, but here is some
feedback. Sorry it is a bit long.
Structural API stuff:
- I still haven't really internalized the need to either have workers
speak directly to anyone other than the person who created them, or
the other use cases that MessageChannels are intended for. There is a
lot of complexity here. I think we need to add some requirements and
motivations to the top of the doc, and some code samples showing the
intended usage before implementors can really decide whether it's
worth taking on.
- It seems like we might want an object that represents workers. This
would allow us put the 'onload' and 'onerror' events from MessagePort
there, instead of on MessagePort, which makes more sense to me (I
don't know what it means for a MessagePort to 'load' or 'error'
outside of the context of a worker). MessagePort.onunload could then
change to 'onclose' to go with the close() method.
It seems like over time, we might want to be able to perform other
operations on a worker and having the worker object might be handy.
I know this is weird wrt GC when combined with MessagePorts, and I
don't have a proposed solution.
- It's odd to me that the way to establish a channel to a worker
depends on whether you are the creator of the worker or not. The
creator gets a MessagePort to a new channel back from createWorker(),
but any other function must pass a new MessagePort over the original
one, and the worker must know to use that secondary port to talk back.
I would prefer to see something like:
void Worker.postMessage(DOMString message)
void Worker.postMessage(DOMString message, MessagePort port)
That way the way to establish a new channel is the same for all
callers. It also has the advantage of looking similar to a window's
postMessage API.
Here is how the previous two suggestions would look together:
var worker = new Worker(foo.js);
worker.onload = function() { ... }
worker.onerror = function() { ... }
worker.onunload = function() { ... } // called when the worker shuts down
worker.sendMessage(hello!);
var channel = new MessageChannel();
channel.port1.onmessage = function(e) { ... }
worker.sendMessage(please return my call, channel.port2);
// called when the channel is closed, either because the worker shut down taking
// the other end of the port with it, or because the other end of the
port was GC'd,
// or because the other port was explicitly closed.
channel.port1.onclose = function() { ... }
semantics questions
- The spec doesn't seem to say what happens if you send a worker a
message before it has finished loading. I think that the message
should be queued and delivered when the worker load is complete. This
makes waiting for onload unnecessary, unless preparing the message you
want to send is somehow expensive.
- The spec says that as soon as a worker is not reachable (determined
via GC) from any MessagePort, it is eligible for shutdown. Shutdown
would attempt to finish all queued messages, but not allow any new
ones.
This concerns me because it means that workers will have different
behavior depending on GC timing. If a worker is not referenced from
any port, and it sends an XHR, that XHR may or may not be sent
depending on when GC runs. This is different than how XHR behaves
normally. Typically, XHR objects that have outstanding IO but no
referers will not be GC'd until they complete or fail.
Finally this does not allow use cases such as creating a worker to
synchronize a local database with the network without ever sending
notifications back to the parent.
Maybe workers should stay alive as long as any of the following are true:
- There is script running in them
- There are messages to them queued
- There is a messageport alive anywhere that could send messages to them
- There are asynchronous operations (xhr, timers, database
operations) inside them outstanding
API nitpickery
- Why is there an ownerWindow property on MessagePort? If I understand
correctly, this is just a synonym for the 'window' object of the
currently executing script context. I think it should go away.
- I'm curious as to why MessagePort and WindowWorker do not implement
EventTarget. It seems like we may as well reuse it. And at least for
WindowWorker, it seems like the same problems of having multiple
functions clobber each other that motivated EventTarget would apply.
- The purpose of 'import()' on WindowWorker was not immediately
obvious to me from its name. Should it be 'importScript()'? or
'includeScript()' maybe?
- Should import() accept an array of URLs, so that the UA can fetch
them in parallel if it has the ability to do that?
- The string URL property on the WindowWorker interface is less useful
than the parsed structure that window.location has. Can we use
something like this instead, except making it read-only?
- The front-line nomenclature was a bit weird to me. How about top-level?
- Would it be too weird to have createWorker overloaded to
Re: [whatwg] Web Workers and MessagePort feedback
Thanks for the quick reply...
On Tue, Aug 5, 2008 at 2:52 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
I know this is weird wrt GC when combined with MessagePorts, and I
don't have a proposed solution.
I don't think we should say much regarding GC at all. All we should say is
that GC should not affect the operation of the page. I.e. it is not allowed
to GC an Worker that someone still has references to, or a Worker that has
XHR loads in progress or timers pending.
Very few other specs mention GC and I haven't noticed that ever being a
problem. For example everyone agrees that it's a bug that gecko sometimes
GCs the parent of a node, if you're not actively holding any references to
anything in the parent chain.
The spec doesn't have to mention GC, but it does mention
'reachability' right now and what happens when an object is no longer
reachable. This has an impact on interop, so I think it should be
well-defined.
Here is how the previous two suggestions would look together:
var worker = new Worker(foo.js);
worker.onload = function() { ... }
worker.onerror = function() { ... }
worker.onunload = function() { ... } // called when the worker shuts down
worker.sendMessage(hello!);
So I really like this API. However it makes it completely impossible to ever
pass worker objects across threads. I.e. we could never allow:
worker1.postMessage(..., worker2);
This would be very strange if we had .onload, .onerror etc on the worker
object itself since those properties wouldn't make much sense living in
multiple threads at once.
While I agree direct communication between sibling workers is an edgecase,
it's something I would prefer to not make impossible for future versions of
the spec.
Though I just realized that we could cover that case using only
MessagePorts. So we say that you can only communicate with your creator, and
any children using direct .postMessage. If you want to more complex
communication patterns then set up MessagePorts.
Makes sense, and I like how this is something that could be layered in
a later version.
- The spec says that as soon as a worker is not reachable (determined
via GC) from any MessagePort, it is eligible for shutdown. Shutdown
would attempt to finish all queued messages, but not allow any new
ones.
This concerns me because it means that workers will have different
behavior depending on GC timing. If a worker is not referenced from
any port, and it sends an XHR, that XHR may or may not be sent
depending on when GC runs. This is different than how XHR behaves
normally. Typically, XHR objects that have outstanding IO but no
referers will not be GC'd until they complete or fail.
Finally this does not allow use cases such as creating a worker to
synchronize a local database with the network without ever sending
notifications back to the parent.
Maybe workers should stay alive as long as any of the following are true:
- There is script running in them
- There are messages to them queued
- There is a messageport alive anywhere that could send messages to them
- There are asynchronous operations (xhr, timers, database
operations) inside them outstanding
Agreed. Like I said above, I think the less we say about GC the better. GC
effects should not be noticeable to the page.
Ok, but right now, the spec says something that contradicts this. It
should either be changed, or removed, if people think the right
behavior goes without saying.
- Why is there an ownerWindow property on MessagePort? If I understand
correctly, this is just a synonym for the 'window' object of the
currently executing script context. I think it should go away.
If we put postMessage directly on the Worker object we don't need to mention
MessagePorts in the Web workers spec at all. They can just be an orthogonal
specs.
This feedback was referencing the separate MessageChannel section of
the web-apps spec. I glommed my feedback together because it was the
first time I'd looked at MessageChannels closely and they go together
for my purposes.
- The string URL property on the WindowWorker interface is less useful
than the parsed structure that window.location has. Can we use
something like this instead, except making it read-only?
Why do we need it at all?
If we do think it's useful, most of the uses that I've seen for the parsed
URL structure has been to set the .hash in order to scroll around on a page
or communicate between iframes of different origins (ugh!!). Neither of
these applies here I'd say.
The protocol, host, hostname, port, pathname, and search properties
are all very useful. An application might want to compare the origin
of a message it receives with it's own host and port, for example.
Providing these split out avoids common parsing mistakes.
- The front-line nomenclature was a bit weird to me. How about
top-level?
I didn't try to grokk this part yet. Is it just about estabilishing lifetime
of the worker objects? If so,
[whatwg] Aborting an in-progress database transaction
It seems like you need a way to abort an in-progress transaction. An easy way to do this would be to add an abort() method to SQLTransaction. Thoughts? - a
[whatwg] database transactions should be serialized
I think this has been covered in passing before, but I wanted to bring it up explicitly. Currently, the database API has an error code for the situation where you open a transaction for read, then try to write but the database is locked. I think that the spec should at least suggest, but perhaps require, implementors to serialize access to a single database to prevent this from happening. Without this, developers must wrap every single write attempt in error handling and retry if a lock error occurs. It seems likely that developers will forget to do this and it will be a significant pain point with the API. Applications will seem to work, but then mysteriously fail in production when users have multiple copies of the application open. Even if the developer adds retry logic, it is easy for a page to get starved by another page. Serializing access would prevent all these problems at the cost of read concurrency, which I think is OK for the first version of this API. A future version of the API could add the concept of read transactions which would allow concurrency, but would fail immediately when you try to write with them. - a
Re: [whatwg] Workers
Wh! How about: - synchronous network access - storage access in general - synchronous db access - access to a subset of the capabilities from the window.location object, for example the href property and the reload method. We have found that some workers want to reload themselves when they find they can no longer communicate with their origin server - access to read and write cookies. We have found that some workers want to be able to modify the cookies for their origins - access to some sort of printline/console debugging facility I still think you should be able to pass JSON-style objects between workers without needing to do the serialization yourself. This allows the implementation to pick a fast way to do the copy without having to go to a string. More importantly, it makes more sense if we're going to allow passing end points between workers too. Without this, you'd have to first pass a message to a worker as a string, then pass the end point. It makes more sense for callers to be able to build up an object parameter that includes strings, booleans, numbers, arrays, objects, and end points, along with any other datatypes we dream up that make sense to be passable. The API is more future-proof this way. Another idea (and something that is present in Gears) is the ability to load workers from another origin. This provides a way to do controlled cross-origin communication that is more lightweight than loading an iframe and doing postMessage() with it. - a On Wed, Jul 9, 2008 at 6:30 PM, Ian Hickson [EMAIL PROTECTED] wrote: Based on popular demand (and threats that without a spec implementations would proceed regardless) I have started collecting use cases and requirements for a specification for background worker scripts (threads) in JavaScript: http://www.whatwg.org/specs/web-workers/current-work/#requirements Any feedback would be greately appreciated, especially from authors involved in large Web applications who would make significant use of such a feature, and from implementors of browsers that may support this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed additions to ClientInformation interface
On Fri, Jun 27, 2008 at 2:04 PM, Brady Eidson [EMAIL PROTECTED] wrote: Second: void makeStandalone(); I think one disadvantage of this approach is that it can only be called in response to a user action if you want to avoid it being used to annoy or spam. It's unfortunate to have an API that can only be called at certain times. On Mon, Jul 7, 2008 at 3:04 PM, Ian Hickson [EMAIL PROTECTED] wrote: browserbutton type=makeapp I like this idea. I think it will be fun (in a good way) to come up with the right mix of a distinctive look for the button/link/whatever and support for customization. Perhaps it would have a distinctive icon, but the styling otherwise (borders, background, font) are up to the author. - a
[whatwg] Database API: transaction can get help open too long
I noticed one unfortunate thing about the new Database API. Because the executeSql() callback holds open the transaction, it is easy to accidentally do intensive work inside there and hold open the transaction too long. A common mistake might be to do a big select and then hold open the transaction while the UI is updated. This could hold open the tx maybe an extra couple hundred ms. A bigger problem would be to do synchronous XHR (for example, in workers). This could hold open the tx for seconds. The right place to do work like this is in transaction()'s success callback. But because the resultsets aren't easily accessible there, I think authors are more likely to do work in executeSql()'s success callback and use transaction()'s success callback less frequently. Off hand about the best solution I can think of to this problem is to have some sort of state on the transaction object that gathers the results. This is not very satisfying though. Does anyone have a better idea? Or think this is not a big enough concern to worry about? - a
Re: [whatwg] link rel=icon sizes
On Fri, May 9, 2008 at 12:37 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: On Fri, 09 May 2008 03:34:21 +0100, Aaron Boodman [EMAIL PROTECTED] wrote: I agree that mismatches will occur in the real world. I think it can be left to the UA as to what to do in that case, as it is a developer mistake. Now I'm not sure if this applies to icon sizes (maybe it doesn't as it's a UI feature) but *a lot* of the HTML5 effort is about defining what to do when people make mistakes. Otherwise market leaders get a competitive advantage and the others have to invest resources into figuring out what the market leader does in case of errors. I think the difference is that there is no defined use for the hints in the first place, hence it is not a big deal to define what to do in the case of error. The UA can decide whether to use the hints, and for what, and what to do in the case of them being wrong. - a
Re: [whatwg] link rel=icon sizes=? What if sizes is incorrect?
On Thu, May 8, 2008 at 7:29 PM, Ernest Cline [EMAIL PROTECTED] wrote: No matter what the spec says, I think we can all agree that once this enters the real world there will be times when the icon size given is wrong. So what to do? At a minimum, I think the behavior called for when dealing with the type attribute is called for: User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use metadata included in the link to the resource to determine its type. However once a mismatch is discovered, does that mean that the icon that has been retrieved should be scaled as if it were an img, or should the icon be discarded and the next icon which matches the available parameters be used instead? I agree that mismatches will occur in the real world. I think it can be left to the UA as to what to do in that case, as it is a developer mistake. In the case of Gears, what we would do is use the (possibly incorrect) icon the developer specified for the instant preview, and then use the correct sizes determined from actually downloading the images when we create the shortcut. - a
Re: [whatwg] link rel=icon width= height=aRe:
On Wed, May 7, 2008 at 7:17 PM, Ian Hickson [EMAIL PROTECTED] wrote: I've added a sizes attribute to link for the icon keyword. It takes a space separated list of keywords consisting of two integers separated by an x or the keyword any. Cool. Thanks for being so responsive on this. - a
Re: [whatwg] link rel=icon width= height=
On Mon, May 5, 2008 at 1:57 PM, Kornel Lesinski [EMAIL PROTECTED] wrote: There isn't much bandwidth to be saved. These icons are going to be downloaded only once. 128x128 PNG icons take only 20-30kb. Without hints as to which file contains which size, the user agent must download up to four separate images before using them. The latency this causes is unacceptable for many use cases. Large PNG file + favicon for smallest sizes may be good enough in most cases. In cases when icon design doesn't scale well, authors could provide additional .ico/.icns files. Why should web developers have to settle for good enough, while desktop application developers get to create many differently sized icons optimized for use in different contexts? When website provides application icons (not favicon) in .icns or .ico files, I think it can be reasonably assumed that these files contain all sizes that are needed for desktop icons, and it doesn't matter which exactly. I don't think that ico or icns format is going to be the common case. These formats require specialized software to create correctly, whereas any image editor can create pngs. - a
Re: [whatwg] link rel=icon width=
On Sat, May 3, 2008 at 5:38 PM, Ernest Cline [EMAIL PROTECTED] wrote: Perhaps, but it means adding attributes to link elements that will only be needed for a single link type. If the use case for these attributes is strong enough to add special purpose attributes for use with only link rel=icon then I dare say that it is strong enough to have a special purpose icon element so as to keep user agents from having to deal with nonsense such as link rel=stylesheet height=32 width=32 Can't that happen anyway? For example, link rel=stylesheet icon16x16 is just as nonsensical. - a
Re: [whatwg] link rel=icon width= height=
On Sat, May 3, 2008 at 8:13 AM, fantasai [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: By contrast, I do not know of any actual need to determine the aspect ratio of an SVG icon or the duration of a sound icon. I do not know of cases where HI guidelines for particular platforms would recommend different choices of icon aspect ratio or sound icon duration. Thus, I suggest we limit ourselves to adding only the info that is actually known to be needed at this time. If UI innovation creates a need for more info, we can add it to the spec then. That's fine, but we shouldn't pick a solution here that requires adding attributes every time we have a similar problem. Why? To me it seems much preferable to separate the attributes of an object into separate name/value pairs then trying to mash them all together into one value. - a
Re: [whatwg] link rel=icon width= height=
On Wed, Apr 30, 2008 at 11:32 AM, Brady Eidson [EMAIL PROTECTED] wrote: Since this is obviously a topic that has sparked a tad of passionate interest and there's not necessarily a clear solution that doesn't make link ugly, what are people's thoughts on adding a new element for icon badging, one that would only be valid within the head? That would work for us, too. - a
Re: [whatwg] link rel=icon width= height=
On Tue, Apr 29, 2008 at 6:52 PM, Ian Hickson [EMAIL PROTECTED] wrote: This is a proposal to add height and width attributes to link specifically for the case of rel=icon, so that authors can provide multiple icons and let the UA decide which to use based on their size (without having to download them all to find out which is best). Opinions? +1 :) FWIW, the reason we want this as opposed to just trying all the icons is that we want to be able to render a confirmation UI that contains the icon immediately, without having to wait for all the icons to download. - a
Re: [whatwg] postMessage() issues
On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: - Processing a reply synchronously is awkward in any case, since you need a callback. I'm not sure I follow this argument, I actually come to the opposite conclusion. Say that a page is communicating with multiple iframes using postMessage, and expect replies from all of them. If postMessage is synchronous it is easy to associate a given reply with a given postMessage call, it's simply the reply you get between the time you make the postMessage call and when it returns. So you could install a generic listener for the message event and let the listener set a global variable. Then you just do a postMessage and pick up the reply from the global variable. If postMessage is asynchronous you need to agree on using some identifier in the messages, or you have to use the pipes mechanism for all communication. Granted, with javascript generators you can almost get the same behavior as for synchronous calling, but that is non-trivial. This is a really good argument. FWIW, I had not considered the case of coordinating between multiple iframes. That does make the async version significantly more complex. IMO, the tradeoff is still worth it, though. And in the future, with something like Hixie's messaging proposal, this problem will go away (because you'll have stateful objects that represent a conversation). So one thing I should note first of all is that the implementation that is currently in the Firefox 3 betas are synchronous. It is unlikely that we can get this changed by final shipping since we are more or less in code freeze already. Of course, we implemented this knowing that it's part of HTML5 which is nowhere near complete, so obviously we were aware that it might change. However it might mean that developers will have to put in workarounds in order to support the FF3 release :( What about if we just left the sync/async-ness unspecified for the first version of postMessage. In practice this means that implementations might be incompatible, but I don't the workarounds are that big a deal. Authors have this problem already today with XHR in certain edge cases (sometimes onreadystatechange is not asynchronous)? In the future, when the messaging proposal evolves, we tighten it down and make it async. - a
Re: [whatwg] postMessage() issues
On Thu, Apr 17, 2008 at 7:22 PM, Ojan Vafai [EMAIL PROTECTED] wrote: IMO, the tradeoff is still worth it, though. And in the future, with something like Hixie's messaging proposal, this problem will go away (because you'll have stateful objects that represent a conversation). I don't understand this argument. Why do you need an identifier? Doesn't e.source point to the frame in question? Oh good point, I take it back. - a
Re: [whatwg] SQL storage API: optional name, version of the openDatabase()
On Thu, Apr 10, 2008 at 9:53 AM, Dimitri Glazkov [EMAIL PROTECTED] wrote: Doh! I apologize. This has not been one of my shiniest moments. In addition to what Aaron says, I actually meant the reverse: only name and version being required (potentially with version optional, as he suggests), and display name and estimated size being optional. I see. My original question doesn't even make sense given that displayName and estimatedSize are not optional. I guess I had gotten used to not thinking about those two parameters because Gears is not planning on using them. Our applications sometimes use multiple databases (because they are stretched across origins) and it does not make sense to put up a dialog for each one. But I don't have a proposal right now, so just ignore this thread. Sorry! - a
