XMLHttpRequest send() Method Uploads On Inappropriate HTTP Protocols
Hello, I noticed that the Mozilla XMLHttpRequest send() method implementation uploads POST data on any protocol other than GET. According to a discussion at Bugzilla, this is due to the specs: http://www.w3.org/TR/XMLHttpRequest/#the-send-method I believe this spec ought to be updated to also exclude POST data from being uploaded for HTTP request methods like DELETE, TRACE, OPTIONS. Plus, I believe upload should be allowed to be send along with HEAD requests, because if the page would usually respond to POST requests, it can only return useful results like Content-length if the HEAD request would upload the same data as POST. For further details on this discussion please refer to: https://bugzilla.mozilla.org/show_bug.cgi?id=547205 Regards, Axel Dahmen www.axeldahmen.de _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969
Re: XMLHttpRequest send() Method Uploads On Inappropriate HTTP Protocols
On Tue, 23 Feb 2010 11:06:20 +0100, Hans Meiser bril...@hotmail.com wrote: I believe this spec ought to be updated to also exclude POST data from being uploaded for HTTP request methods like DELETE, TRACE, OPTIONS. As I said in the bug, we do not want to constrain HTTP more than we already do. Plus, I believe upload should be allowed to be send along with HEAD requests, because if the page would usually respond to POST requests, it can only return useful results like Content-length if the HEAD request would upload the same data as POST. I do not understand what you mean here. GET/HEAD are semantically equivalent, not HEAD/POST. -- Anne van Kesteren http://annevankesteren.nl/
RE: XMLHttpRequest send() Method Uploads On Inappropriate HTTP Protocols
Hi Anne, I believe this spec ought to be updated to also exclude POST data from being uploaded for HTTP request methods like DELETE, TRACE, OPTIONS. As I said in the bug, we do not want to constrain HTTP more than we already do. I believe this is not a question of wanting but a question of definition and browser compatibility. Plus, I believe upload should be allowed to be send along with HEAD requests, because if the page would usually respond to POST requests, it can only return useful results like Content-length if the HEAD request would upload the same data as POST. I do not understand what you mean here. GET/HEAD are semantically equivalent, not HEAD/POST. Yes, sure. But a HEAD request is usually being used to obtain a web server's headers on a specific resource. If that resource is configured to respond to POST requests only (e.g. a PHP page responding to uploaded form data), the headers returned by this resource ought to be the same headers a HEAD request would obtain. So if a web server's resource would respond to a HTTP POST request with headers containing, e.g., Content-length information (or any header computed from the uploaded POST data) then a HEAD request should yield the same headers. Otherwise the HEAD information retrieved would be useless in order to take decisions on whether to load the full resource using a POST request. Do you see my point? Best regards, Axel Dahmen www.axeldahmen.de _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
Re: XMLHttpRequest send() Method Uploads On Inappropriate HTTP Protocols
On Tue, 23 Feb 2010 12:29:59 +0100, Hans Meiser bril...@hotmail.com wrote: I believe this spec ought to be updated to also exclude POST data from being uploaded for HTTP request methods like DELETE, TRACE, OPTIONS. As I said in the bug, we do not want to constrain HTTP more than we already do. I believe this is not a question of wanting but a question of definition and browser compatibility. Indeed. And as such we are doing the right thing here. Plus, I believe upload should be allowed to be send along with HEAD requests, because if the page would usually respond to POST requests, it can only return useful results like Content-length if the HEAD request would upload the same data as POST. I do not understand what you mean here. GET/HEAD are semantically equivalent, not HEAD/POST. Yes, sure. But a HEAD request is usually being used to obtain a web server's headers on a specific resource. If that resource is configured to respond to POST requests only (e.g. a PHP page responding to uploaded form data), the headers returned by this resource ought to be the same headers a HEAD request would obtain. No: http://tools.ietf.org/html/rfc2616#section-9.4 So if a web server's resource would respond to a HTTP POST request with headers containing, e.g., Content-length information (or any header computed from the uploaded POST data) then a HEAD request should yield the same headers. Otherwise the HEAD information retrieved would be useless in order to take decisions on whether to load the full resource using a POST request. Do you see my point? I think so, but I believe you are wrong. -- Anne van Kesteren http://annevankesteren.nl/
RE: XMLHttpRequest send() Method Uploads On Inappropriate HTTP Protocols
OK, I see... Given this definition then, the case is closed. However, I see a lack in the definition regarding resources obtained by a POST request: Not ALL headers will be returned with expected values if uploaded data is not going to be sent to the host. Best regards, www.axeldahmen.de Axel Dahmen _ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
Re: Notifications
This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they live with the constraints of that notification system, but either way it's a tradeoff that the user can make. And yes, in the near term some of this may be prohibitive on mobile devices, but so are many things (try as they might, mobile browsers still aren't a pleasure to work with when it comes to viewing large complex sites or sites that use flash, etc). I strongly believe that web applications are increasing in number, in scope, and are becoming an integral part of people's lives. As web applications expand, I don't think it is unreasonable to believe that support for HTML in the platform (e.g. HTML in notification providers) will happen some day. It's not going to be immediate, and so I have outlined some ideas that I hope may get us moving in the meanwhile, but I don't want us to fall victim to the argument of well, right now it's hard so let's not do it. My $0.02. Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com: On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.com wrote: On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx This is a useful data point. It does seem like the major platforms are conforming to a simple icon + title + text interface for ambient notifications. The microsoft API seems more aligned with NotifyOSD (non-interactable notifications with a transient status tray icon provided to allow the user to click). I
Re: Notifications
Hi, Ian- I generally agree with you, and certainly with your sentiment. Not to go all SVG on you, but why *HTMLNotification? I understand that HTML is really common, and that increasingly SVG can be used as part of HTML, but there are lots of devices out there (TVs, mobiles, set-top boxes) that use SVG rather than HTML, which would benefit from these interactive notifications... shouldn't we define a more generic CreateWebNotification and pass an optional MIME Type parameter that defaults to text/html (or some similar mechanism)? I strongly agree with the sentiment that we should design for the future, in any case, and not limit ourselves to simple text notifications. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM): This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they live with the constraints of that notification system, but either way it's a tradeoff that the user can make. And yes, in the near term some of this may be prohibitive on mobile devices, but so are many things (try as they might, mobile browsers still aren't a pleasure to work with when it comes to viewing large complex sites or sites that use flash, etc). I strongly believe that web applications are increasing in number, in scope, and are becoming an integral part of people's lives. As web applications expand, I don't think it is unreasonable to believe that support for HTML in the platform (e.g. HTML in notification providers) will happen some day. It's not going to be immediate, and so I have outlined some ideas that I hope may get us moving in the meanwhile, but I don't want us to fall victim to the argument of well, right now it's hard so let's not do it. My $0.02. Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com mailto:john...@google.com: On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.com mailto:atwil...@google.com wrote: On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi mailto:hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a
Web services and Rich Internet Applications documentation request
Can someone point me to documentation on what is being developed in this Working Group in the way of web services that specifically serve the needs of Rich Internet Applications? I am a technology reporter covering RIAs. Links would be great. Best Regards, David Geer 440-964-9832 http://www.linkedin.com/in/technologycontent This message may be privileged or confidential. If you are not the intended recipient, please delete it without reading. If you received this message in error, please notify the sender at once.
Re: Notifications
This seems like a balance and all around reasonable way to move forward. 2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they live with the constraints of that notification system, but either way it's a tradeoff that the user can make. And yes, in the near term some of this may be prohibitive on mobile devices, but so are many things (try as they might, mobile browsers still aren't a pleasure to work with when it comes to viewing large complex sites or sites that use flash, etc). I strongly believe that web applications are increasing in number, in scope, and are becoming an integral part of people's lives. As web applications expand, I don't think it is unreasonable to believe that support for HTML in the platform (e.g. HTML in notification providers) will happen some day. It's not going to be immediate, and so I have outlined some ideas that I hope may get us moving in the meanwhile, but I don't want us to fall victim to the argument of well, right now it's hard so let's not do it. My $0.02. Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com: On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.comwrote: On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx This is a useful data point. It does seem like the major platforms are conforming to a simple icon + title + text interface for
Re: Web services and Rich Internet Applications documentation request
Replied offline... Cheers On Tue, 23 Feb 2010 19:28:46 +0100, David Geer da...@geercom.com wrote: Can someone point me to documentation on what is being developed in this Working Group in the way of web services that specifically serve the needs of Rich Internet Applications? I am a technology reporter covering RIAs. Links would be great. Best Regards, David Geer 440-964-9832 http://www.linkedin.com/in/technologycontent This message may be privileged or confidential. If you are not the intended recipient, please delete it without reading. If you received this message in error, please notify the sender at once. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Notifications
Doug - I did not mean to be HTML centric, apologies. I'm currently going through a debate in my mind (scary thing) about whether allowing an arbitrary mime type and content would be good or bad. My gut sense here is that if the UA is capable of displaying it, we should allow it, and it will be used or not used (with fallbacks provided) based on the support of UAs, with more UAs evolving to support it as user demand grows. Ideally we would provide multiple fallbacks, e.g. allow someone to specify an ordered list in order of preference, e.g. text/html representation followed by image/svg+xml followed by text/plain (although perhaps text/plain is better left broken out, so that it's more visible and people actually fill it in, as opposed to being some option in a list of things you can provide). e.g. CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. At any rate, I'm not opposed to what you propose, just trying to think out loud of how to best do that while still ensuring that a text fallback is still reasonably simple (and obvious) to specify. -Ian Am 23. Februar 2010 10:24 schrieb Doug Schepers schep...@w3.org: Hi, Ian- I generally agree with you, and certainly with your sentiment. Not to go all SVG on you, but why *HTMLNotification? I understand that HTML is really common, and that increasingly SVG can be used as part of HTML, but there are lots of devices out there (TVs, mobiles, set-top boxes) that use SVG rather than HTML, which would benefit from these interactive notifications... shouldn't we define a more generic CreateWebNotification and pass an optional MIME Type parameter that defaults to text/html (or some similar mechanism)? I strongly agree with the sentiment that we should design for the future, in any case, and not limit ourselves to simple text notifications. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM): This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they
Re: Notifications
Hi, Ian- No need to apologize... HTML is a little bit more widely adopted than SVG (I suspect that there are 10x as many HTML documents as SVG documents on the Web). It may be that only specifying text and HTML notifications is the best way forward for now, I just wanted to make sure it was an informed decision. I agree with the simplicity goal. Fallbacks and defaults make a lot of sense to me. I'll noodle a bit and see if I can come up with a simple mechanism, but I'm probably happier reviewing other people's proposals. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 2:20 PM): Doug - I did not mean to be HTML centric, apologies. I'm currently going through a debate in my mind (scary thing) about whether allowing an arbitrary mime type and content would be good or bad. My gut sense here is that if the UA is capable of displaying it, we should allow it, and it will be used or not used (with fallbacks provided) based on the support of UAs, with more UAs evolving to support it as user demand grows. Ideally we would provide multiple fallbacks, e.g. allow someone to specify an ordered list in order of preference, e.g. text/html representation followed by image/svg+xml followed by text/plain (although perhaps text/plain is better left broken out, so that it's more visible and people actually fill it in, as opposed to being some option in a list of things you can provide). e.g. CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. At any rate, I'm not opposed to what you propose, just trying to think out loud of how to best do that while still ensuring that a text fallback is still reasonably simple (and obvious) to specify. -Ian Am 23. Februar 2010 10:24 schrieb Doug Schepers schep...@w3.org mailto:schep...@w3.org: Hi, Ian- I generally agree with you, and certainly with your sentiment. Not to go all SVG on you, but why *HTMLNotification? I understand that HTML is really common, and that increasingly SVG can be used as part of HTML, but there are lots of devices out there (TVs, mobiles, set-top boxes) that use SVG rather than HTML, which would benefit from these interactive notifications... shouldn't we define a more generic CreateWebNotification and pass an optional MIME Type parameter that defaults to text/html (or some similar mechanism)? I strongly agree with the sentiment that we should design for the future, in any case, and not limit ourselves to simple text notifications. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM): This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave
Re: Notifications
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. -Ian -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
Doug Schepers wrote (on 2/23/10 2:43 PM): HTML is a little bit more widely adopted than SVG (I suspect that there are 10x as many HTML documents as SVG documents on the Web). I've been told offlist that it may not be obvious that I was joking here... 10x is an absurdly low figure... HTML is many orders of magnitude more common on the Web than SVG (or PDF, or Word, or Flash, or txt, or pretty much anything else). :) Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Notifications
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. I suspect that text fallback + a single URL would be sufficient. As a fallback/escape hatch, servers can sniff UA headers and serve up a different data type if a non-HTML-supporting device starts supporting this API. -Ian -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com: Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. Yes, there are several features, such as video and img that have fallback. However this is because there is no alternative other than simply not introducing these features. I.e. we can't redesign video in such a way that fallback for blind people isn't needed, due to inherit visual properties of video. The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. I'm sure that if you ask any blind person they will tell you that the amount of fallback provided for img is no where near enough. And I'm fairly certain this isn't due to the fact that the majority of web authors don't care about blind people. So while I agree with some of your arguments, I don't at all buy the argument that there are other features out there that use fallback, so it's ok here too, or if people care, they'll provide fallback. / Jonas
Re: Notifications
Am 23. Februar 2010 13:44 schrieb Jonas Sicking jo...@sicking.cc: 2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com: Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. Yes, there are several features, such as video and img that have fallback. However this is because there is no alternative other than simply not introducing these features. I.e. we can't redesign video in such a way that fallback for blind people isn't needed, due to inherit visual properties of video. The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. I'm sure that if you ask any blind person they will tell you that the amount of fallback provided for img is no where near enough. And I'm fairly certain this isn't due to the fact that the majority of web authors don't care about blind people. So while I agree with some of your arguments, I don't at all buy the argument that there are other features out there that use fallback, so it's ok here too, or if people care, they'll provide fallback. / Jonas That's not really an accurate restating of my position. I am saying if no text fallback is specified, let's try to create one from what is given to us. Unlike with video and images, we actually have a reasonable chance of being able to create something intelligible here. Not perfect, but a lot different from the case of here's an image with no alt text, now I will just cry.
File URN lifetimes and SharedWorkers
This was recently brought to my attention by one of the web app developers in my office: http://dev.w3.org/2006/webapi/FileAPI/#lifetime User agents MUST ensure that the lifetime of File URN #dfn-fileURNs is the same as the lifetime of the Document [HTML5 #HTML5] of the origin script which spawned the File #dfn-file object on which the urn #dfn-urn attribute was called. When this Document is destroyed, implementations MUST treat requests for File URN #dfn-fileURNs created within thisDocument as 404 Not Found.[Processing Model #processing-model-urn for File URN #dfn-fileURN s] I'm curious how this should work for SharedWorkers - let's imagine that I create a File object in a document and send it to a SharedWorker via postMessage() - the SharedWorker will receive a structured clone of that File object, which it can then access. What should the lifetime of the resulting URN for that file object be? I suspect the intent is that File objects ought to be tied to an owning script context rather than to a specific Document (so, in this case, the lifetime of the resulting URN would be the lifetime of the worker)? -atw
Re: Notifications
2010/2/23 Jonas Sicking jo...@sicking.cc The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. One of the reasons I stepped back from this discussion is because it seemed clear that we weren't going to make progress on solutions until we had agreement on requirements (specifically, the amount of interaction that we want to enable in these notifications). The non-fallback proposals that have been put forward aren't acceptable to me for the same reasons that Jonas is opposed to the fallback proposals - we both have a different vision for what the requirements should be. I'd like to see us focus on gaining some consensus around requirements, because I think the rest of these disagreements will mostly resolve themselves once we do that. -atw
[WebSQLDatabase] openDatabase() creation callback
Hi,
I know that not many people on this list care about the WebSQLDatabase spec
anymore (especially when it comes to changing it), but Chromium extension
developers do. So I was hoping somebody could explain the idea behind having
openDatabase() take a creationCallback. As I understand it, the callback is
supposed to be a place where the user initiates the DB (changes version,
creates tables, etc.). However, if we follow the spec, then this callback
becomes quite useless.
*Example 1:*
function creationCallback(db) {
db.transaction(...); // change version, create tables, etc.
}
var db = openDatabase(..., creationCallback);
db.transaction(tx1);
db.transaction(tx2);
According to the spec, if the database doesn't exist, we must queue a task
to run creationCallback (4.1) and return from openDatabase(). Then we queue
up tasks for the 2 transactions (4.3.2). So our queue ends up looking like
this:
1. invoke creationCallback
2. invoke the transaction callback for tx1
3. invoke the transaction callback for tx2
Now we invoke creationCallback, and find a transaction there, so we queue up
a task to invoke the transaction callback (4.3.2). Now our queue looks like
this:
1. invoke transaction callback for tx1
2. invoke transaction callback for tx2
3. invoke transaction callback for the transaction defined inside
creationCallback
As you can see, if we follow the spec, we end up running the transaction(s)
in creationCallback AFTER all other transactions in the code. So what's the
point of having a creationCallback?
*Example 2:*
function creationCallback(db) {
db.changeVersion(...); // change version to 1.0
}
var db1 = openDatabase(db, 1.0, , 1, creationCallback);
var db2 = openDatabase(db, 1.0, , 1);
According to the spec, if db doesn't exist, then the first openDatabase()
will set the version to (empty string) and queue up the creationCallback.
Now before we have a chance to invoke the creationCallback, the second call
to openDatabase() happens, and fails with a INVALID_STATE_ERR (as requested
by the spec), because a database with that name exists, it's version is ,
and we expect the version to be 1.0. So again, the creationCallback which
was supposed to change the version comes in after the rest of the code has
already failed.
So it seems to me that if we follow the spec, then the creationCallback
becomes nothing more than a flag that tells us whether or not the DB existed
(and a pretty poor implementation of such a flag too, since it's set only
after we're done executing the rest of the code). Is this really the
intended purpose of this callback? If not, assuming the purpose of this
callback was to initialize the database before running any transactions on
it, I propose the following changes to the spec:
1. If the database doesn't exist and a creationCallback is specified, *
invoke* the creation callback at the very end of openDatabase(). (This would
take care of the problem described in example 1.)
2. If the database doesn't exist, always set its version to the given one.
If a creation callback was specified, invoke it. If the creation callback
fails or raises an exception, reset the database version to . (This would
take care of the problem in example 2. And in case creationCallback fails,
we will reset the DB version to before any other transaction gets a
chance to run.)
Thanks,
dumi
