Re: [whatwg] XMLHttpRequest for missing file
2007/6/29, Geoffrey Garen:
The XMLHttpRequest spec has this to say about failed loads:
snip
The NETWORK_ERR exception is thrown when a network error occurs in
synchronous requests.
...
In case of network errors
In case of DNS errors or other type of networks run the following set
of steps.This does not include HTTP responses that indicate some type
of error, such as HTTP status code 410.
/snip
What should happen with failed file:/// URL loads? For example, what
if the file doesn't exist?
I'd personnaly like the browser emulates a 404, but that's not what
browsers do today:
Firefox raises an exception:
QueryInterface: function QueryInterface() { [native code] }
message: Component returned failure code: 0x80520012
(NS_ERROR_FILE_NOT_FOUND) [nsIXMLHttpRequest.send]
result: 2152857618
name: NS_ERROR_FILE_NOT_FOUND
IE7 too:
name: TypeError
message: Accès refusé.
number: -2147024891
description: Accès refusé.
Opera doesn't raise an exception. The status is 0 !?
Safari 3 for Windows raises this exception:
message: NETWORK_ERR: XMLHttpRequest Exception 101
code: 101
line: 10
sourceURL:
file:///C:/Documents%20and%20Settings/tbr/Mes%20documents/Mes%20Projets/test.html
Test file:
!doctype html
script
var xhr;
if (window.XMLHttpRequest)
xhr = new XMLHttpRequest();
else if (window.ActiveXObject)
xhr = new ActiveXObject(Microsoft.XMLHTTP);
try {
xhr.open(GET, file:///C|/nonexistentfile, false);
xhr.send(null);
if (xhr.readyState == 4)
alert(xhr.status);
} catch (e) {
for (var i in e)
document.write(i + ': ' + e[i] + 'br');
}
/script
iframe src=file://C|/nonexistentfile/iframe
--
Thomas Broyer
Re: [whatwg] XMLHttpRequest for missing file
Safari 3 for Windows raises this exception: For the record, I've just now changed Safari (WebKit) to stop throwing that exception, which matches Safari 2. Geoff
[whatwg] Parsing: Greater-than characters in doctype
All browsers terminate the doctype at the first character, even if it's inside the public identifier or system identifier. I think the spec should reflect this by adding: U+003E GREATER-THAN SIGN () Parse error. Set the DOCTYPE token's correctness flag to incorrect. Emit that DOCTYPE token. Switch to the data state. ...to the DOCTYPE public identifier (double-quoted), DOCTYPE public identifier (single-quoted), DOCTYPE system identifier (double-quoted), and DOCTYPE system identifier (single-quoted) states. -- Simon Pieters
Re: [whatwg] Parsing: Greater-than characters in doctype
On Jun 29, 2007, at 11:59, Simon Pieters wrote: U+003E GREATER-THAN SIGN () Parse error. Set the DOCTYPE token's correctness flag to incorrect. Emit that DOCTYPE token. Switch to the data state. Should the string (public id or system id) that was being built be dropped on the floor as well? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Parsing: Greater-than characters in doctype
On Fri, 29 Jun 2007 11:20:38 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: On Jun 29, 2007, at 11:59, Simon Pieters wrote: U+003E GREATER-THAN SIGN () Parse error. Set the DOCTYPE token's correctness flag to incorrect. Emit that DOCTYPE token. Switch to the data state. Should the string (public id or system id) that was being built be dropped on the floor as well? I don't see a good reason to drop it. The doctype's correctness flag is set to incorrect anyway. But I don't feel strongly about it either way. -- Simon Pieters
Re: [whatwg] Parsing: Greater-than characters in doctype
On Fri, 29 Jun 2007 11:26:44 +0200, Stewart Brodie [EMAIL PROTECTED] wrote: Simon Pieters [EMAIL PROTECTED] wrote: All browsers terminate the doctype at the first character, even if it's inside the public identifier or system identifier. I see this sort of comment a lot - I think it would be really helpful if people could state which browsers they have actually tested, because you clearly cannot have tested all browsers. IE, Firefox, Safari and Opera aren't all browsers (especially if you only test one specific version) Oops! Seems my testing went wrong somewhere. IE doesn't do this. IE seems to not emit the token for that is in quotes anywhere for both doctypes and bogus comments (or it treats doctypes as bogus comments): !doctype ! ? / This does not apply to these: !-- -- -- % % % -- Simon Pieters
Re: [whatwg] Parsing: Greater-than characters in doctype
Simon Pieters [EMAIL PROTECTED] wrote: All browsers terminate the doctype at the first character, even if it's inside the public identifier or system identifier. I see this sort of comment a lot - I think it would be really helpful if people could state which browsers they have actually tested, because you clearly cannot have tested all browsers. IE, Firefox, Safari and Opera aren't all browsers (especially if you only test one specific version) -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] XMLHttpRequest for missing file
IE7 does not allow XML-HTTP-Requesting a local file whether it exists or not. You can use Scripting.FileSystemObject for that purpose. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey Garen Sent: Friday, June 29, 2007 6:39 AM To: [EMAIL PROTECTED] Subject: [whatwg] XMLHttpRequest for missing file The XMLHttpRequest spec has this to say about failed loads: snip The NETWORK_ERR exception is thrown when a network error occurs in synchronous requests. ... In case of network errors In case of DNS errors or other type of networks run the following set of steps.This does not include HTTP responses that indicate some type of error, such as HTTP status code 410. /snip What should happen with failed file:/// URL loads? For example, what if the file doesn't exist? Thanks, Geoff
[whatwg] Fwd: XMLHttpRequest for missing file
Oops, sorry, answered to public-html instead of whatwg, resend... 2007/6/29, Kristof Zelechovski: IE7 does not allow XML-HTTP-Requesting a local file whether it exists or not. Yes, and note that other browsers I've tested (Firefox, Opera 9 and Safari for Windows) return 0 as xhr.status and an empty string as xhr.statusText when the file exists. -- Thomas Broyer
[whatwg] .localName shouldn't change case
For HTML elements in HTML documents, why is Element.localName uppercased for tag names and lowercased for attribute names? I wouldn't expect it to, and it makes it harder to write scripts that work for both HTML and XHTML. For example, if you want a script to work in both legacy HTML UAs and HTML5 UAs as well as in XHTML, you may want to do something like if ((elm.tagName == A !elm.namespaceURI) || (elm.localName == a elm.namespaceURI == http://www.w3.org/1999/xhtml;)) to check that a given element is an HTML a element. -- Simon Pieters
Re: [whatwg] .localName shouldn't change case
On Jun 29, 2007, at 9:15 AM, Simon Pieters wrote: For HTML elements in HTML documents, why is Element.localName uppercased for tag names and lowercased for attribute names? I wouldn't expect it to, and it makes it harder to write scripts that work for both HTML and XHTML. For example, if you want a script to work in both legacy HTML UAs and HTML5 UAs as well as in XHTML, you may want to do something like if ((elm.tagName == A ! elm.namespaceURI) || (elm.localName == a elm.namespaceURI == http://www.w3.org/1999/xhtml;)) to check that a given element is an HTML a element. Good timing, mentioning this. WebKit uses lowercase for localName for HTML elements in HTML documents for the reasons you mention. We received a bug report about a library, Jira, that doesn't work with Safari 3 because of this http://bugs.webkit.org/show_bug.cgi? id=14114. We were surprised to learn that Mozilla uses uppercase. -- Darin
Re: [whatwg] .localName shouldn't change case
2007/6/29, Simon Pieters:
For HTML elements in HTML documents, why is Element.localName uppercased
for tag names and lowercased for attribute names?
Because of this:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-5353782642
and this:
http://www.w3.org/2000/11/DOM-Level-2-errata#html-2
I wouldn't expect it to, and it makes it harder to write scripts that work for
both HTML and XHTML. For example, if you want a script to work in both
legacy HTML UAs and HTML5 UAs as well as in XHTML, you may want
to do something like if ((elm.tagName == A !elm.namespaceURI) ||
(elm.localName == a elm.namespaceURI ==
http://www.w3.org/1999/xhtml;)) to check that a given element is an
HTML a element.
Actually, if you wanted such drastic checks, you'd need yet another
condition, because HTML5 puts HTML elements in the XHTML namespace:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-terminology.html#html-namespace
So I'd just recommend:
if (elm.localName.lower() == a) { ... }
or eventually:
if (elm.localName.lower() == a
(!elm.namespaceURI
|| elm.namespaceURI == http://www.w3.org/1999/xhtml;)) {
}
if you're working in documents with other namespaces.
--
Thomas Broyer
Re: [whatwg] Gears design goals
Sorry it took me awhile to respond. Work intruded. On 6/26/07, Robert O'Callahan [EMAIL PROTECTED] wrote: Right now I think we're missing just one thing from your list of goals (excluding the vexatious multiple resources for one URI goal): a way to get consistent updates without relying on JAR files (and hence changing URIs). As I mentioned earlier, I think we can get that by simply stating (and implementing!) that updates to all offline-cached resources in a domain --- that were requested by pages in the same domain --- occur atomically as a group, similar to what Gears does. That leaves one issue, which is the ability to add new resources as part of such an atomic update; to get that, we probably should add an offline-manifest DOM API or link type, which pulls in a JSON manifest and requests all the resources in it. That sounds good. Gears team has also considered that you could get consistent versions without the hard version number we currently have in the manifests. It seems like right now, all items in a domain implicitly form an atomic group. Is that right? A couple issues some Gears people brought up with this: * It's likely to significantly slow down revalidation. There could be many, many resources linked with the programmatic api (again, think of attachments). All these would have to be revalidated each time the app is viewed. * It seems like atomic groups and domains are not 1-to-1. Lots of times separate applications are hosted on the same domain but in different directories. I guess it's not dangerous to revalidate all apps under a domain when any are viewed, but it seems like a waste. You could mitigate the first issue by allowing the developer to say whether a certain resource should be part of the domain's atomic group. I am not sure how to mitigate the second issue except for by telling developers to use separate domains for separate applications. Maybe this is not a big problem. Another thought that we had was that it would be good if whatever you can do with the link tag syntax, you can also do programmatically. It may be difficult to hook into IE deep enough to implement the link tag syntax. If so, that means apps can't serve different resources at the same URL, even when a connection is available, which seems like a big constraint. Sure they can. The user can only have one active login per browser session anyway, so the app just swaps in a whole new set of resources when the user logs in with a different ID. The only restriction is that when the user's offline, they'll only be able to use the last ID that they logged in as. Let me put the strongest spin on this that I can :-) --- I'm reluctant to substantially complicate the API for implementors and developers for all time, just so that some legacy apps can have an easier transition for the specific case of supporting multiple logins while the user is offline. Fair enough. And if application developers want to support multiple offline logins, they can still write their app in a way to support that. - a
Re: [whatwg] .localName shouldn't change case
On Fri, 29 Jun 2007 19:22:49 +0200, Thomas Broyer [EMAIL PROTECTED]
wrote:
2007/6/29, Simon Pieters:
For HTML elements in HTML documents, why is Element.localName uppercased
for tag names and lowercased for attribute names?
Because of this:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-5353782642
and this:
http://www.w3.org/2000/11/DOM-Level-2-errata#html-2
I had hoped that, since .localName doesn't work in IE, that content didn't
rely on it returning uppercase in HTML (but rather only use it in XML
contexts).
I wouldn't expect it to, and it makes it harder to write scripts that
work for
both HTML and XHTML. For example, if you want a script to work in both
legacy HTML UAs and HTML5 UAs as well as in XHTML, you may want
to do something like if ((elm.tagName == A !elm.namespaceURI) ||
(elm.localName == a elm.namespaceURI ==
http://www.w3.org/1999/xhtml;)) to check that a given element is an
HTML a element.
Actually, if you wanted such drastic checks, you'd need yet another
condition, because HTML5 puts HTML elements in the XHTML namespace:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-terminology.html#html-namespace
If .localName didn't return uppercase, then the check would work.
So I'd just recommend:
if (elm.localName.lower() == a) { ... }
or eventually:
if (elm.localName.lower() == a
(!elm.namespaceURI
|| elm.namespaceURI == http://www.w3.org/1999/xhtml;)) {
}
if you're working in documents with other namespaces.
Yeah. The case where you have an A element in the
http://www.w3.org/1999/xhtml; namespace (which isn't an a element)
probably isn't worth worrying about...
--
Simon Pieters
[whatwg] html start tag token in the root element phase
If the spec dealt with the html start tag token directly in the root element phase, the parse error in the main phase wouldn't need to be conditional. (Implementations that experience a perf benefit from not mutating the attributes of a node probably want to hoist the html node creation to the root element phase for perf reasons, too.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Gears design goals
On Jun 26, 2007 4:26 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: On 6/27/07, Aaron Boodman [EMAIL PROTECTED] wrote: Great! So where do we differ on the implementation of those goals? Is there an up-to-date spec I can read? http://www.campd.org/stuff/Offline%20Cache.html Right now I think we're missing just one thing from your list of goals (excluding the vexatious multiple resources for one URI goal): a way to get consistent updates without relying on JAR files (and hence changing URIs). As I mentioned earlier, I think we can get that by simply stating (and implementing!) that updates to all offline-cached resources in a domain --- that were requested by pages in the same domain --- occur atomically as a group, similar to what Gears does. That leaves one issue, which is the ability to add new resources as part of such an atomic update; to get that, we probably should add an offline-manifest DOM API or link type, which pulls in a JSON manifest and requests all the resources in it. So I don't know why one would want to maintain atomicity at the domain level as opposed to the application level. When I run an application I want to make sure I get the latest version of the application. Not sure why it would mean that I want to make sure that I update all the applications from that domain. This could place an unnecessary load on the servers for no great gain for the user. Am I missing something? Andy
Re: [whatwg] Gears design goals
On Jun 26, 2007 4:26 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: On 6/27/07, Aaron Boodman [EMAIL PROTECTED] wrote: If so, that means apps can't serve different resources at the same URL, even when a connection is available, which seems like a big constraint. Sure they can. The user can only have one active login per browser session anyway, so the app just swaps in a whole new set of resources when the user logs in with a different ID. The only restriction is that when the user's offline, they'll only be able to use the last ID that they logged in as. The problem with this is what happens when two users share the same machine. Not unusual with families and laptops. So my kid and I both have an offline enabled version of a application X. My kid was the last one runing X before leaving on a trip. I open the laptop and fire up X. From what I believe you said, I can't see my version of X. This is a problem if the versions are actually different. One could (as Aaron did for Gearpad) down load all the code and dynamically use it depending on the user, but that can be expensive to do, especially as applications grow in size. For example in our initial tests it bacame clear that we would download different resources depending on the language setting for the user. You would not want to download all the languages for the application. If the user changed languages then we would recapture the application. Yes this does limit the user from changing languages when offline, but changing languages is a rare event and forcing the user to be online seemed to be a reasonable tradeoff. The downloading of different code per user also is useful for supporting web applications that provide different functionality depending on the user. This can occur if the application is tiered (e.g. you get a basic version for free, and the premium version for a fee) or when the application is slowly rolled out to the user community.
Re: [whatwg] .localName shouldn't change case
On Jun 29, 2007, at 10:22 AM, Thomas Broyer wrote: 2007/6/29, Simon Pieters: For HTML elements in HTML documents, why is Element.localName uppercased for tag names and lowercased for attribute names? Because of this: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-5353782642 and this: http://www.w3.org/2000/11/DOM-Level-2-errata#html-2 If you look at the part of the spec that is actually normative for HTML, it only requires this behavior for tagName and nodeName. There is no such requirement for localName. 1.6.3. Exposing Element Type Names (tagName, (nodeName)) If the document is an HTML 4.01 document the element type names exposed through a property are in uppercase. For example, the body element type name is exposed through the tagName property as BODY. If the document is an XHTML 1.0 document the element name is exposed as it is written in the XHTML file. This means that the element type names are exposed in lowercase for XHTML documents since the XHTML 1.0 DTDs defines element type names as lowercase, and XHTML, being derived from XML, is case sensitive. DOM Level 2 Core does not call for any special case behavior for localName either. Although it says that localName should be null for HTML elements created with createElement, which seems wrong: For nodes of any type other than ELEMENT_NODE and ATTRIBUTE_NODE and nodes created with a DOM Level 1 method, such as createElement from the Document interface, this is always null.. It would be silly to have a null localName for dynamically created HTML elements only, and even more silly to do so for all HTML elements. We originally made tagName/nodeName uppercase but localName lowercase in WebKit so that you'd get the required HTML behavior for the first two, but localName would show through to a more XML-like view, so it could be used together with namespaceURI and you wouldn't have to care whether the document was XML or not. I still think the WebKit behavior is nice in theory, although it appears to be a compat issue. Regards, Maciej
Re: [whatwg] Gears design goals
On 6/30/07, Andy Palay [EMAIL PROTECTED] wrote: So I don't know why one would want to maintain atomicity at the domain level as opposed to the application level. When I run an application I want to make sure I get the latest version of the application. Not sure why it would mean that I want to make sure that I update all the applications from that domain. Simplicity, mainly. Scoping updates (and the offlineResources list) to the domain level means we don't have to define a new abstraction that delimits application boundaries. And it lets us avoid any issues with partially overlapping applications. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Gears design goals
On 6/30/07, Andy Palay [EMAIL PROTECTED] wrote: On Jun 26, 2007 4:26 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: Sure they can. The user can only have one active login per browser session anyway, so the app just swaps in a whole new set of resources when the user logs in with a different ID. The only restriction is that when the user's offline, they'll only be able to use the last ID that they logged in as. The problem with this is what happens when two users share the same machine. Not unusual with families and laptops. So my kid and I both have an offline enabled version of a application X. My kid was the last one runing X before leaving on a trip. I open the laptop and fire up X. From what I believe you said, I can't see my version of X. This is a problem if the versions are actually different. For this scenario people can use OS user switching or browser profiles --- or, of course, the Web app can be modified to avoid giving multiple resources the same URI. (My eldest son is five years old and already I can see that letting him share my browser session is a bad idea :-) ) One could (as Aaron did for Gearpad) down load all the code and dynamically use it depending on the user, but that can be expensive to do, especially as applications grow in size. For example in our initial tests it bacame clear that we would download different resources depending on the language setting for the user. You would not want to download all the languages for the application. If the user changed languages then we would recapture the application. Yes this does limit the user from changing languages when offline, but changing languages is a rare event and forcing the user to be online seemed to be a reasonable tradeoff. I'm not quite sure what you're getting at, but let's suppose a Web app does want to support multiple users sharing a single offline browser profile and those users need different languages. (I think this is already a rather narrow scenario, FWIW.) We'd ask the app author to give user-specific resources user-specific URIs. For resources, such as help pages, that are language specific but not user specific, we'd ask the author to give them language-specific URIs (e.g. including /en/ or whatever). Each user's manifest pulls in the appropriate resources, and precisely the required language resources are downloaded. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Gears design goals
On 6/29/07, Robert O'Callahan [EMAIL PROTECTED] wrote: I'm not quite sure what you're getting at, but let's suppose a Web app does want to support multiple users sharing a single offline browser profile and those users need different languages. (I think this is already a rather narrow scenario, FWIW.) We'd ask the app author to give user-specific resources user-specific URIs. For resources, such as help pages, that are language specific but not user specific, we'd ask the author to give them language-specific URIs ( e.g. including /en/ or whatever). Each user's manifest pulls in the appropriate resources, and precisely the required language resources are downloaded. I think as you tried more and more languages, you'd get more resources associated with the domain. And so the number of resources that would need to get revalidated on each view of the app would get larger. This doesn't seem like a huge problem, just trying to make sure I understand things correctly. - a
Re: [whatwg] Gears design goals
On 6/30/07, Aaron Boodman [EMAIL PROTECTED] wrote: On 6/26/07, Robert O'Callahan [EMAIL PROTECTED] wrote: Right now I think we're missing just one thing from your list of goals (excluding the vexatious multiple resources for one URI goal): a way to get consistent updates without relying on JAR files (and hence changing URIs). As I mentioned earlier, I think we can get that by simply stating (and implementing!) that updates to all offline-cached resources in a domain --- that were requested by pages in the same domain --- occur atomically as a group, similar to what Gears does. That leaves one issue, which is the ability to add new resources as part of such an atomic update; to get that, we probably should add an offline-manifest DOM API or link type, which pulls in a JSON manifest and requests all the resources in it. That sounds good. Gears team has also considered that you could get consistent versions without the hard version number we currently have in the manifests. It seems like right now, all items in a domain implicitly form an atomic group. Is that right? Right now as in what I've proposed, yes. Not right now as in what's implemented on Firefox trunk :-) A slight twist is needed actually: an atomic group consists of all resources in a domain that are used by pages in the same domain. We allow cross-domain references but we do not allow them to create consistency requirements. A couple issues some Gears people brought up with this: * It's likely to significantly slow down revalidation. There could be many, many resources linked with the programmatic api (again, think of attachments). All these would have to be revalidated each time the app is viewed. For the specific case of attachments, in our model those could be placed in their own domain. For resources where you actually want to access the contents on the client, wouldn't work. * It seems like atomic groups and domains are not 1-to-1. Lots of times separate applications are hosted on the same domain but in different directories. I guess it's not dangerous to revalidate all apps under a domain when any are viewed, but it seems like a waste. You could mitigate the first issue by allowing the developer to say whether a certain resource should be part of the domain's atomic group. I am not sure how to mitigate the second issue except for by telling developers to use separate domains for separate applications. That's what I would suggest, yes. Another thought that we had was that it would be good if whatever you can do with the link tag syntax, you can also do programmatically. It may be difficult to hook into IE deep enough to implement the link tag syntax. I think we're there already (although in our proposal, all you'd have to do is traverse the link tags on onload, dynamic changes to the link tags after that have no effect). Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Gears design goals
On 6/30/07, Aaron Boodman [EMAIL PROTECTED] wrote: I think as you tried more and more languages, you'd get more resources associated with the domain. And so the number of resources that would need to get revalidated on each view of the app would get larger. I don't think so --- just serve a manifest for each user that lists the resources for that user's language only. Is there a problem with that I'm not seeing? Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Gears design goals
On 6/29/07, Robert O'Callahan [EMAIL PROTECTED] wrote: On 6/30/07, Aaron Boodman [EMAIL PROTECTED] wrote: I think as you tried more and more languages, you'd get more resources associated with the domain. And so the number of resources that would need to get revalidated on each view of the app would get larger. I don't think so --- just serve a manifest for each user that lists the resources for that user's language only. Is there a problem with that I'm not seeing? Manifest? I thought we were talking about the Mozilla proposal. If you're referring to the list of link tags as a manifest, here is what I am thinking: If you visit http://a.com and it serves you a page linking to: base.js en/1.html And then later you come back and it serves you a page linking to: base.js fr/1.html You have to revalidate all three files, right? You don't know whether en/1.html depends on base.js. I am probably missing something totally obvious :-) - a
Re: [whatwg] Gears design goals
But it does place a very large burdon on the servers. Google would expect to have quite a few applications and my guess is the last thing we would want is to keep pinging every application to see if it up to date whenever any application is used. In fact while we want to make sure the user has the most up to date version we don't need to check on every use. In most cases the current captured version will be fine. The only time that is not the case is when the old version has been made obsolete by a newer version. Unfortunately this can occur at anytime, including when the application is running. So in that case the server needs to tell the client application that it has to force an immediate reload. So the client can always run the currently saved app, check for updates at a convenient time (and in reality not too often). As for shared code, I believe it is a problem but one that can be ignored right now. It does require each app to host all of its own pages. To do anything else moves us in the direction of shared libraies which will open up a can of worms that can be avoided for now. On Jun 29, 2007 3:34 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: On 6/30/07, Andy Palay [EMAIL PROTECTED] wrote: So I don't know why one would want to maintain atomicity at the domain level as opposed to the application level. When I run an application I want to make sure I get the latest version of the application. Not sure why it would mean that I want to make sure that I update all the applications from that domain. Simplicity, mainly. Scoping updates (and the offlineResources list) to the domain level means we don't have to define a new abstraction that delimits application boundaries. And it lets us avoid any issues with partially overlapping applications. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Gears design goals
On 6/30/07, Aaron Boodman [EMAIL PROTECTED] wrote: On 6/29/07, Robert O'Callahan [EMAIL PROTECTED] wrote: On 6/30/07, Aaron Boodman [EMAIL PROTECTED] wrote: I think as you tried more and more languages, you'd get more resources associated with the domain. And so the number of resources that would need to get revalidated on each view of the app would get larger. I don't think so --- just serve a manifest for each user that lists the resources for that user's language only. Is there a problem with that I'm not seeing? Manifest? I thought we were talking about the Mozilla proposal. I mentioned earlier that to get consistent updates without JARs, we have to add manifest support. Dave is working on it. I think he's following the Gears manifest format. Speak up Dave :-) If you visit http://a.com and it serves you a page linking to: base.js en/1.html And then later you come back and it serves you a page linking to: base.js fr/1.html You have to revalidate all three files, right? You don't know whether en/1.html depends on base.js. You mean the other way around? In this case http://a.com would have to list all resources used by the application. If en/1.html is no longer listed, it is not used by the application (i.e. not used by base.js) and will not be revalidated. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Gears design goals
On 6/30/07, Andy Palay [EMAIL PROTECTED] wrote: But it does place a very large burdon on the servers. Google would expect to have quite a few applications and my guess is the last thing we would want is to keep pinging every application to see if it up to date whenever any application is used. My Google apps currently use mail.google.com, docs.google.com, picasaweb.google.com ... Calendar uses www.google.com, I don't know why :-) So most of these apps have their own domains, and won't face a problem here. Is it overly burdensome to put separate apps in their own domains? If it is, then I would suggest simply allowing consistency to be partitioned by directory as well. I'm not sure of the best way for the server to configure that, though. In fact while we want to make sure the user has the most up to date version we don't need to check on every use. In most cases the current captured version will be fine. The only time that is not the case is when the old version has been made obsolete by a newer version. Unfortunately this can occur at anytime, including when the application is running. So in that case the server needs to tell the client application that it has to force an immediate reload. So the client can always run the currently saved app, check for updates at a convenient time (and in reality not too often). Yep. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Gears design goals
On 6/30/07, Robert O'Callahan [EMAIL PROTECTED] wrote: If it is, then I would suggest simply allowing consistency to be partitioned by directory as well. I'm not sure of the best way for the server to configure that, though. One option would be to use an HTTP header to allow each resource to say what consistency group it belongs to. Say X-Consistency-Group: http://www.google.com/calendar;. When the header is omitted the default is just the scheme + domain. This would have the nice property that if a browser doesn't implement support for the header, everything still works, revalidation is just slower. For resources like attachments where you don't want consistency, you could just set X-Consistency-Group to the resource's own URI. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
