Re: [WebTiming] HTMLElement timing
On Thu, Jan 28, 2010 at 10:53 PM, Zhiheng Wang zhihe...@google.com wrote:
Also, what is the use case for the Ticks interface?
The Ticks interface is a convenient way to store time measurements
and
retrieve it later on a page.
I will have some example there.
Why not just do:
myTimings = {};
myTimings.fooStart = new Date();
etc? Javascript has perfectly good ways to store values already.
window.timing property keeps timing info of previous navigation as well
so the Tick
interface also provides a way to pass custom POI to the next page. Some
security
measure need to be added later though.
Sounds like simply using
sessionStorage.myTimings = {};
sessionStorage.myTimings.fooStart = new Date();
I would really encourage that this spec be reduced to the most
important parts first and wait for browsers to catch up before adding
nice to have features.
Agree and we do keep that in mind. Most of the the properties
specified
right now are
on the critical path of user perceived latency though.
That surprises me. See my first answer above.
I meant these properties are in the latency critical path of the element
it belongs to...
If implementations implement progress events on the various elements
it would seem like you would get most of the advantages from this
spec.
The progress events are great, except that they mostly focus on
downloading the content but
not much about everything else, say, parseStart.
Specs can be changed, nothing is set in stone :)
Good to know. :-) Having more data exported in the progress events will
be
good news to those performance debugging tools. When collecting latency
field data, many developers perfer to fetch all timing info of an
element (window.document?)
at once and send a json object.
thanks,
Zhiheng
While I agree that timing information is important, I don't think it's
going to be so commonly used that we need to add convenience features
for it. Adding a few event listeners at the top of the document does
not seem like a big burden.
/ Jonas
One feature, multiple resources
This is an excerpt of something I wrote on the #webapps IRC channel: arve hm arve I have some exploratory work here (not going into details) arve let's just say that param for feature isn't enough arve but an example is actually Opera's own Unite arve (looking a bit further, though) arve let's say I wanted to spawn two workers, each with their own web service arve simply speaking, I can't arve currently, all I can do is: arve feature name=http://xmlns.opera.com/webserver; arve param name=type value=service / arve param name=servicepath value=foo / arve /feature The problem is roughly that the param key-value pair is insufficient when a feature needs to both specify and configure multiple resources, such as one Opera Unite widget configuring two different web services. The example above could only ever load one single service per widget (and it would be what's specified in the widget's content element, to boot). A widget which wanted to configure one document per widget would need to nest the param's in something. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
[XHR] New api request
Hi, how interest is for you develop new APIs in order to enable a reuse of the XMLHttpRequest objects, without the need to call abort method? -- Pedro Henrique Oliveira dos Santos
[widgets-interface] Marking Widget as [NoInterfaceObject]
Hi, http://www.w3.org/TR/2009/CR-widgets-apis-20091222/#the-widget-interface currently declares the Widget interface without extended attributes. I believe it is not the goal of the specification to expose the interface itself in the global namespace, so I think it should be marked with a [NoInterfaceObject] extended attribute. There is also a typo in the note under the declaration of the interface: e.g., a user agent can to support (probably missing the verb choose). Dom
Re: Window id - an idea to make multi page web application easier
Sebastian, All, On Jan 18, 2010, at 10:54 AM, ext Sebastian Hennebrueder wrote: About half a year ago I came up with an idea to add a unique window id as request header to each browser request. I published this initially on my website http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html Now, I have stumbled upon the WebApps Working Group and would like to introduce this here as well. WebApp'ers - does anyone have any feedback for Sebastian? Would this idea be more applicable to HTML5? -Art Barstow
Re: [WebTiming] HTMLElement timing
On 1/27/10 9:39 AM, Zhiheng Wang wrote: Folks, Thanks to the much feedback from various developers, the WebTiming specs has undergone some major revision. Timing info has now been extended to page elements and a couple more interesting timing data points are added. The draft is up on http://dev.w3.org/2006/webapi/WebTiming/ Feedback and comments are highly appreciated. cheers, Zhiheng Like Jonas mentioned, this kind of information could be exposed using progress events. What is missing in the draft, and actually in the emails I've seen about this is the actual use case for the web. Debugging web apps can happen outside the web, like Firebug, which investigates what browser does in different times. Why would a web app itself need all this information? To optimize something, like using different server if some server is slow? But for that (extended) progress events would be good. And if the browser exposes all the information that the draft suggest, it would make sense to dispatch some event when some new information is available. There are also undefined things like paint event, which is referred to in lastPaintEvent and paintEventCount. And again, use case for paintEventCount etc. The name of the attribute is very strange: readonly attribute DOMTiming document; What is the reason for timing array in window object? Why do we need to know anything about previous pages? Or what is the timing attribute about? -Olli
Re: Window id - an idea to make multi page web application easier
Arthur Barstow schrieb: Sebastian, All, On Jan 18, 2010, at 10:54 AM, ext Sebastian Hennebrueder wrote: About half a year ago I came up with an idea to add a unique window id as request header to each browser request. I published this initially on my website http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html Now, I have stumbled upon the WebApps Working Group and would like to introduce this here as well. WebApp'ers - does anyone have any feedback for Sebastian? Would this idea be more applicable to HTML5? -Art Barstow Hi Art, thank you for the feedback. HTML 5 defines precise scopes for per window or per browser which can be used by JavaScript. The missing bit is to pass a window id to the server with the HTTP request. I don't know to which spec this actually belongs to. I am hoping that people here can help me or finally convince me that my idea is useless. -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/29 Ian Fette (イアンフェッティ) ife...@google.com 2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: * Parameter: size * Values: [integer | button | toolbar | toolbarsmall | menu | dialog] * Description: If integer, this is the desired size in square pixels of the icon * Else, use the OS default for the specified keyword context. integer scales the icons to the desired size. I think we'd at least need a few different sizes for a default set of icons. I'm not sure that such icons exist. -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam -- Pierre.
Re: localStorage Event
Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is actually what brought this to my attention. I cannot think of an example where iframe's would not be sufficient as a work-around, however it could potentially be inconvenient to use them, especially when your app may be open in several tabs. Each other tab would get two events triggered, one for the primary document and one for the iframe inside of it. While this isn't the end of the world, clearly you would need to always check the source of the iframe event, to make sure it came from it's parent, and not another tab. Between this and Olli's prototype suggestion, it is clear there are definitely ways around this issue should a developer face it. However, I do think the advantage of having your glue code written for you would be of great benefit to developers. -J On Thu, Jan 28, 2010 at 3:06 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse jarc...@gmail.com wrote: Perhaps I am mistaken, but I believe you would still have to go around and add that trigger to all the places the value is changed from. That is true. Can you give some clear examples of when having local storage events being fired in your frame would be useful? Bonus points if they're something that can't be handled by simply creating an iframe within your doc and using it to monitor events (which is the obvious work-around). J On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
We could change it to fire in all windows and have a boolean that says whether you fired it. Maybe that's the best solution? On Fri, Jan 29, 2010 at 10:33 AM, Jared Morse jarc...@gmail.com wrote: Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is actually what brought this to my attention. I cannot think of an example where iframe's would not be sufficient as a work-around, however it could potentially be inconvenient to use them, especially when your app may be open in several tabs. Each other tab would get two events triggered, one for the primary document and one for the iframe inside of it. While this isn't the end of the world, clearly you would need to always check the source of the iframe event, to make sure it came from it's parent, and not another tab. Between this and Olli's prototype suggestion, it is clear there are definitely ways around this issue should a developer face it. However, I do think the advantage of having your glue code written for you would be of great benefit to developers. -J On Thu, Jan 28, 2010 at 3:06 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse jarc...@gmail.com wrote: Perhaps I am mistaken, but I believe you would still have to go around and add that trigger to all the places the value is changed from. That is true. Can you give some clear examples of when having local storage events being fired in your frame would be useful? Bonus points if they're something that can't be handled by simply creating an iframe within your doc and using it to monitor events (which is the obvious work-around). J On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
That would be a good solution in my opinion, although if you wanted to check if the event was dispatched by the current document or another, I believe you could use the source property that the spec currently contains, and just do something like: ev.source == window ? That seems to work as expected in Safari 4.0.4 (I assume production builds of Chrome as well). -J On Fri, Jan 29, 2010 at 10:36 AM, Jeremy Orlow jor...@chromium.org wrote: We could change it to fire in all windows and have a boolean that says whether you fired it. Maybe that's the best solution? On Fri, Jan 29, 2010 at 10:33 AM, Jared Morse jarc...@gmail.com wrote: Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is actually what brought this to my attention. I cannot think of an example where iframe's would not be sufficient as a work-around, however it could potentially be inconvenient to use them, especially when your app may be open in several tabs. Each other tab would get two events triggered, one for the primary document and one for the iframe inside of it. While this isn't the end of the world, clearly you would need to always check the source of the iframe event, to make sure it came from it's parent, and not another tab. Between this and Olli's prototype suggestion, it is clear there are definitely ways around this issue should a developer face it. However, I do think the advantage of having your glue code written for you would be of great benefit to developers. -J On Thu, Jan 28, 2010 at 3:06 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse jarc...@gmail.com wrote: Perhaps I am mistaken, but I believe you would still have to go around and add that trigger to all the places the value is changed from. That is true. Can you give some clear examples of when having local storage events being fired in your frame would be useful? Bonus points if they're something that can't be handled by simply creating an iframe within your doc and using it to monitor events (which is the obvious work-around). J On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
The source parameter was taken out of the spec for a while ago. And it never worked in Chrome because the window may be in another process (and we don't handle/allow cross-process scripting). J On Fri, Jan 29, 2010 at 11:13 AM, Jared Morse jarc...@gmail.com wrote: That would be a good solution in my opinion, although if you wanted to check if the event was dispatched by the current document or another, I believe you could use the source property that the spec currently contains, and just do something like: ev.source == window ? That seems to work as expected in Safari 4.0.4 (I assume production builds of Chrome as well). -J On Fri, Jan 29, 2010 at 10:36 AM, Jeremy Orlow jor...@chromium.orgwrote: We could change it to fire in all windows and have a boolean that says whether you fired it. Maybe that's the best solution? On Fri, Jan 29, 2010 at 10:33 AM, Jared Morse jarc...@gmail.com wrote: Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is actually what brought this to my attention. I cannot think of an example where iframe's would not be sufficient as a work-around, however it could potentially be inconvenient to use them, especially when your app may be open in several tabs. Each other tab would get two events triggered, one for the primary document and one for the iframe inside of it. While this isn't the end of the world, clearly you would need to always check the source of the iframe event, to make sure it came from it's parent, and not another tab. Between this and Olli's prototype suggestion, it is clear there are definitely ways around this issue should a developer face it. However, I do think the advantage of having your glue code written for you would be of great benefit to developers. -J On Thu, Jan 28, 2010 at 3:06 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse jarc...@gmail.com wrote: Perhaps I am mistaken, but I believe you would still have to go around and add that trigger to all the places the value is changed from. That is true. Can you give some clear examples of when having local storage events being fired in your frame would be useful? Bonus points if they're something that can't be handled by simply creating an iframe within your doc and using it to monitor events (which is the obvious work-around). J On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
Re: localStorage Event
Ah, well then I think your suggestion would be ideal. -J On Fri, Jan 29, 2010 at 11:25 AM, Jeremy Orlow jor...@chromium.org wrote: The source parameter was taken out of the spec for a while ago. And it never worked in Chrome because the window may be in another process (and we don't handle/allow cross-process scripting). J On Fri, Jan 29, 2010 at 11:13 AM, Jared Morse jarc...@gmail.com wrote: That would be a good solution in my opinion, although if you wanted to check if the event was dispatched by the current document or another, I believe you could use the source property that the spec currently contains, and just do something like: ev.source == window ? That seems to work as expected in Safari 4.0.4 (I assume production builds of Chrome as well). -J On Fri, Jan 29, 2010 at 10:36 AM, Jeremy Orlow jor...@chromium.orgwrote: We could change it to fire in all windows and have a boolean that says whether you fired it. Maybe that's the best solution? On Fri, Jan 29, 2010 at 10:33 AM, Jared Morse jarc...@gmail.com wrote: Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is actually what brought this to my attention. I cannot think of an example where iframe's would not be sufficient as a work-around, however it could potentially be inconvenient to use them, especially when your app may be open in several tabs. Each other tab would get two events triggered, one for the primary document and one for the iframe inside of it. While this isn't the end of the world, clearly you would need to always check the source of the iframe event, to make sure it came from it's parent, and not another tab. Between this and Olli's prototype suggestion, it is clear there are definitely ways around this issue should a developer face it. However, I do think the advantage of having your glue code written for you would be of great benefit to developers. -J On Thu, Jan 28, 2010 at 3:06 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse jarc...@gmail.comwrote: Perhaps I am mistaken, but I believe you would still have to go around and add that trigger to all the places the value is changed from. That is true. Can you give some clear examples of when having local storage events being fired in your frame would be useful? Bonus points if they're something that can't be handled by simply creating an iframe within your doc and using it to monitor events (which is the obvious work-around). J On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 1/28/10 11:57 PM, Jared Morse wrote: Even though it occurs on the same document, doesn't mean loosely coupled code can't benefit from it. Imagine if each time you added a feature to a web app that depended on knowing a current value from the storage, you'd have to go around to all the places that value is changed and add some code to alert your new code. If storage events triggered on the same document, all you would have to do is set a listener. If you really need this behavior, you can always dispatch your own event to the window when you change the data. -Olli -J On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 1/28/10 9:34 PM, Jared Morse wrote: Hi, I have a concern about the web storage event spec (http://dev.w3.org/html5/webstorage/). The spec states: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired... My concern lies with the other than x part. Unless I'm missing something, these events would be even more useful if they also fired in the HTMLDocument that initially made the storage call. The page which is changing storage object knows already that the storage object is being changed. Why would it need explicit notification (event) about that? -Olli Thanks for your time. -Jared
[widgets] follow-ups on the URI scheme spec
Re the URI scheme spec, there have been some followups on other publicly archived mail lists. In chronological order: 1. Jan 25 from Larry Masinter: http://lists.w3.org/Archives/Public/www-archive/2010Jan/0075.html 2. Jan 29 from Art Barstow: http://lists.w3.org/Archives/Public/www-archive/2010Jan/0090.html 3. Jan 29 from Larry Masinter (also copied below): http://lists.w3.org/Archives/Public/public-ietf-w3c/2010Jan/0006.html AFAICTell, no one ever responded to Robin's 15-June-2009 e-mail about the thismessage: scheme: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0972.html It doesn't seem like it would be appropriate for the spec to contain text about its relationship to other schemes although including a pointer to non-normative text about other related schemes would be OK, e.g. what we created months ago: http://www.w3.org/2008/webapps/wiki/WidgetURIScheme -Art Barstow Begin forwarded message: From: ext Larry Masinter masin...@adobe.com Date: January 29, 2010 1:03:44 PM EST To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com Cc: Robin Berjon ro...@berjon.com, Doug Schepers schep...@w3.org, www-archive www-arch...@w3.org, public-ietf- w3c public-ietf-...@w3.org, Graham Klyne g...@ninebynine.org Subject: RE: [widgets] Draft Minutes for 21 January 2010 voice conference (moving to public w3c/ietf list, not administrative one) With regard to comments on the widget: URI scheme. What does clear utility mean in this context and where is the measurement criteria? Where can we find an objective and measurable definition of broad Internet community? In particular, where can I find a list of the members of this community and is this community self-selected? These are great questions. I think the guidelines within the IETF (e.g., http://www.ietf.org/tao.html) use the word community without defining it precisely. I suppose the community is self-selected only in the sense that anyone who posts on an IETF mailing list should be given a voice. And of course clear and utility are subjective enough; I suppose when we wrote that in the URI guidelines we imagined that this wouldn't be hard actually be hard to do! I mean, it was my opinion that the registration document doesn't show why widget://garbage/stuff is more useful than thismessage:/stuff since garbage isn't defined in the document. If the document explained how it was useful (you know, like even gave a hint of a use case), then the utility would likely be clearer. If there are a lot of people who think something isn't clear, clarifying the document will improve the chances that more people will think it is clear, enough to believe that the community generally thinks it is clear. I gave my opinion. I'm surprised you can't just try a little harder to clarify things, rather than try to formally ask for a precise definition of clear utility. The measurement criteria aren't defined, but the process is. The process is expert review; and if the expert wants, the expert can call for IETF review and IESG decision. Anyway, in this process, I'm not a gatekeeper; I *do* think the IETF process should be followed and the criteria for new URI schemes met, and I don't think you have to work so hard to do that. I mean, if you really can't easily come up with a use case where you can use widget: and you couldn't use thismessage:, and put that use case in the document, where's the clear utility? Larry
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Wed, Jan 27, 2010 at 4:46 PM, Kris Zyp k...@sitepen.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A few comments I've been meaning to suggest: * count on KeyRange - Previously I had asked if there would be a way to get a count of the number of objects within a given key range. The addition of the KeyRange interface seems to be a step towards that, but the cursor generated with a KeyRange still only provides a count property that returns the total number of objects that share the current key. There is still no way to determine how many objects are within a range. Was the intent to make count return the number of objects in a KeyRange and the wording is just not up to date? Otherwise could we add such a count property (countForRange maybe, or have a count and countForKey, I think Pablo suggested something like that). * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises To piggyback on these suggestions, in prototyping a couchdb-backed store for Kris Zyp's perstore [1], which uses IndexedDB as the store API, I came across a major use case that can't be supported by the IndexedDB API as defined: couchdb's MVCC model requires an object's revision (ETag) for a DELETE. There are obviously plenty of other values (for instance, conditional HTTP header values) that could be critical -- or just very helpful -- to pass into a store's CRUD (get, put, and delete) methods. Initially we thought we could just extend the API by tacking on an *options*object to each of the CRUD method signatures but this feels hacky -- especially given that put has a third boolean noOverwrite argument defined. Would it be feasible to specify an options object for get, put and delete (which could house noOverwrite). Certainly the IndexedDB API cannot possibly conceive of every use case -- explicitly defining this kind of extension point would be helpful while keeping the method signatures sane. Speaking of noOverwrite, perhaps it is my unfamiliarity with WebIDL but the semantics are not entirely clear. AFAICT the overwrite characteristics of a put could be any of MUST be an insert, MUST be an update, or insert OR update. I see that noOverwrite is defined as optional boolean which suggests it could be true, false or undefined, potentially supporting any of these three cases -- true: insert, false: update, undefined: insert OR update. However only the true case is explicitly defined as throwing on failure (MUST be an insert), implying the false|undefined case is insert OR update. This does not allow disambiguating the MUST update case (e.g. HTTP If-Match: *), which seems problematic, or at the very least like a missed opportunity. (Also, a bikeshed: noOverwrite seems unnecessarily convoluted -- overwrite: true for update | false for insert | undefined for either is a bit more intuitive.) [1] http://github.com/kriszyp/perstore
Re: The most basic File API use case
On Wed, Dec 16, 2009 at 11:58 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Dec 16, 2009 at 9:55 AM, Robin Berjon ro...@berjon.com wrote:
Hi Jonas,
On Dec 10, 2009, at 19:42 , Jonas Sicking wrote:
On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon ro...@berjon.com wrote:
[Constructor(DOMString mediaType, DOMString fileName)]
interface FileWriter {
// saving operations
void save (DOMString content, optional DOMString encoding, optional
DOMString endings);
void save (Blob data);
Hmm.. I'm not entirely convinced that it's worth having the first of
these two methods. You're already up to two optional arguments, and
more might be needed (such as if to include a BOM or not). It might be
simpler to simply require people to create Blobs and then save that
Blob.
I could live with other options but there are things that are quite specific
to writing text, amongst them at the very least using the same encoding
throughout (which is clumsy if you have to append several times to a blob
and specify it every time. I thought of having a TextBlob that could take
encoding, line endings, BOM, etc. as parameters to its constructor and then
passing that to save() but I'm not entirely sure that what we get from the
change is really valuable.
But if to need to append several times then you can't use the above
interface anyway, can you?
How about:
void save (DOMString content, TextOptions options);
where the second argument would be an object literal that could capture all
of this?
Another option would be:
Blob textToBlob (DOMString content, TextOptions options);
I don't really see that this would be much more convenient than:
bb = new BlobBuilder;
bb.appendText(myString, ...);
filewriter.save(bb.getBlob());
possibly on another interface but again I'm not sure what that gains us. Do
we have use cases for textual blobs being used elsewhere? If yes, then I'm
thinking:
interface TextBlobBuilder {
attribute DOMString content;
attribute DOMString encoding;
attribute DOMString endings;
attribute boolean BOM;
Blob generateBlob ();
};
Thoughts?
I don't think I understand this proposal. Can you elaborate, or show
code that would use this?
// abort the save
void abort();
// state codes
const unsigned short INITIAL = 0;
const unsigned short WRITING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
// error, same as FileReader but with some additions
readonly attribute FileError error;
// event handler attributes
attribute Function onloadstart;
attribute Function onprogress;
attribute Function onload;
attribute Function onabort;
attribute Function onerror;
attribute Function onloadend;
I think most of this is overkill. What is the use case for progress
events here? I.e. why does the page need to know how much data has
been written? And why would you want to abort writing the file?
Well, if there are use cases for reading, the same apply for writing. If you
build a large file (e.g. for graphics editing) and save it to a slow storage
(e.g. network drive, SIM) then it could take a very measurable amount of
time (this happens in Photoshop even on powerful computers), and if it does
you probably want to inform the user and to provide her with a way to give
up.
This is essentially a mirror of FileReader; I think it makes sense and not
just for consistency.
Well.. I'm still not convinced that anyone will actually use progress
events for reading files.
I think progress events are reasonable for anything that might take a
long time. If you're loading/saving a large movie file from/to a
network filesystem, it's good to be able to tell the difference
between the action being hung and the write making slow progress.
This way you can show the user a progress bar.
The idea of allowing the page to start a write and then aborting it
scares me a little. And I'm not sure I see the use case. For example I
could imagine implementations running a virus scan on the data before
bringing up the save as dialog, or checking if the page is trying to
write an executable. In these cases a call to abort() could then cause
slightly different data to be written to disc than was originally
checked.
If you're able to generate the data to be saved programmatically, you
can do write a byte at a time, and you can generate it after asking
for permission to save the file. I don't think it makes sense to run
a scanner on it before it hits the disk, so I don't think there's any
security issue here that's not also there in any case where you can
write arbitrary files to the disk.
I guess removing the abort() call would make me feel easier about
this. Or specifying that a call to abort() causes all the data written
so far to be deleted.
My question still remains what the use case for abort() is though.
Abort() is useful if the user gets sick of
