Re: [widgets] Does anyone still care about Widget Updates?
On 14 May 2013, at 15:00, Marcos Caceres wrote: On Tuesday, 14 May 2013 at 14:32, Arthur Barstow wrote: Scott indicated [1] Wookie implemented Widget Updates and Chaals indicated [2] he would followup with Opera but I couldn't find a response from them in the list archive. Do we have two (complete?) implementations of the spec? Opera, Richard? It's not clear to me if we should drop this spec (i.e. publish as a WG Note) or if there are sufficient resource commitments to continue to advance it along the REC track. Marcos - what is the status of the test suite http://dev.w3.org/2006/waf/widgets-updates/test-suite/? (The Implementation Report doesn't look good http://dev.w3.org/2006/waf/widgets-updates/imp-report/.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0256.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0261.html Unless someone else wants to take this, I suggest we just publish as a note. Well, we implemented it and it works, but I'd be fine with it being published as a Note. -- Marcos Caceres PGP.sig Description: This is a digitally signed message part
Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement
Thanks for the feedback! On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote: IDBKeyRange.inList looks practically useful, but it can be achieve continue (continuePrimary) cursor iteration. Performance will be comparable except multiple round trip between js and database. I'm sorry, but I don't understand this bit. How do you envision getting the cursor in the first place here without a way to form a query based on an arbitrary key list? I'm sure I'm just missing an obvious part of the API here. Querying by parallel multiple get in a single transaction should also be fast as well. Yes, Jonas Sicking did recommend a possible optimization for the multiple get() within a transaction. It would seem to me, however, that this will likely impose some cost on the general single get() case. It would be nice if the client had the ability to be explicit about their use case vs using a heuristic to infer it. In any case, I plan to prototype this in the next week or two. Additionally IDBKeyRange.inList violate contiguous key range nature of IDBKeyRange. It is assumed in some use case, like checking a key in the key range or not. If this feature are to be implemented, it should not mess with IDBKeyRange, but directly handle by index batch request. Good point. I suppose an IDBKeySet or IDBKeyList type could be added. Ignoring deplicating keys is not a useful feature in query. In fact, I will like result be respective ordering of given key list. Well, I would prefer to respect ordering as well. I just assumed that people would prefer not to impose that on all calls. Perhaps the cases could be separated: IDBKeyList.inList([]) // unordered IDBKeyList.inOrderedList([]) // ordered I would be happy to include duplicate keys as well. Thanks again. Ben
Re: A very preliminary draft of a URL spec
On 13 May 2013 05:34, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: https://dvcs.w3.org/hg/**webapps/raw-file/81f24bfc5970/**url/url.htmlhttps://dvcs.w3.org/hg/webapps/raw-file/81f24bfc5970/url/url.html In the end I didn't copy Anne's spec beyond believeing him about some Unicode points when I was offline. So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. As the more astute (read people who look at the spec for a few seconds with at least some level of attention) will notice, this needs work. I would be very pleased to receive comments that help clarify things the spec gets wrong, doesn't specify, or doesn't explain clearly. I hope there will be a bugzilla component really very soon, but I neglected to request one so far. If Mike happens to be reading, I'd be grateful for him to do the magic before I get around to writing the request. In the meantime I guess you should just reply to the thread... And no, it doesn't use futures. Sorry. At some point I will come back with the answer to a request for a way to change that. +1 Chaals, I welcome this effort It's tempting (especially on the whatwg ML) to think that the browser is the web. But the URL is used in many contexts in and outside the browser. Please do post the link to the issue tracker when it's up, and hopefully a some of us on WHATGW can help you and Anne in creating a stable and up to date home for this important work. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: A very preliminary draft of a URL spec
On 5/20/13 12:54 PM, ext Melvin Carvalho wrote: On 13 May 2013 05:34, Charles McCathie Nevile cha...@yandex-team.ru mailto:cha...@yandex-team.ru wrote: I hope there will be a bugzilla component really very soon, but I neglected to request one so far. Please do post the link to the issue tracker when it's up, and hopefully a some of us on WHATGW can help you and Anne in creating a stable and up to date home for this important work. The URL spec's bugzilla component is https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=URL
Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement
On Mon, May 20, 2013 at 6:37 AM, Ben Kelly bke...@mozilla.com wrote: Thanks for the feedback! On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote: IDBKeyRange.inList looks practically useful, but it can be achieve continue (continuePrimary) cursor iteration. Performance will be comparable except multiple round trip between js and database. I'm sorry, but I don't understand this bit. How do you envision getting the cursor in the first place here without a way to form a query based on an arbitrary key list? I'm sure I'm just missing an obvious part of the API here. Here's an example I whipped up: https://gist.github.com/inexorabletash/5613707 Querying by parallel multiple get in a single transaction should also be fast as well. Yes, Jonas Sicking did recommend a possible optimization for the multiple get() within a transaction. It would seem to me, however, that this will likely impose some cost on the general single get() case. It would be nice if the client had the ability to be explicit about their use case vs using a heuristic to infer it. In any case, I plan to prototype this in the next week or two. Thanks for taking this on - we'll be watching your implementation experience closely. :) Some discussion here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595 (That also links to a very raw document with other IDB v2 thoughts c/o a very informal google/moz brainstorming session.) One approach that adds generally useful primitives to IDB is (1) something akin to a key range that is a list of keys (per above) and (2) batch cursors that deliver up to N values at a time. Either of those is quite useful independently. Additionally IDBKeyRange.inList violate contiguous key range nature of IDBKeyRange. It is assumed in some use case, like checking a key in the key range or not. If this feature are to be implemented, it should not mess with IDBKeyRange, but directly handle by index batch request. Good point. I suppose an IDBKeySet or IDBKeyList type could be added. I'm not entirely convinced that's necessary. I don't believe we expose is in range in the platform currently, so exposing a new type to script seems excessive. On the other hand, range is a pretty well defined concept in general so it would be a shame to break it. Ignoring deplicating keys is not a useful feature in query. In fact, I will like result be respective ordering of given key list. Well, I would prefer to respect ordering as well. I just assumed that people would prefer not to impose that on all calls. Perhaps the cases could be separated: IDBKeyList.inList([]) // unordered IDBKeyList.inOrderedList([]) // ordered I would be happy to include duplicate keys as well. Thanks again. Ben
Re: [IndexedDB] IDBRequest.onerror for DataCloneError and DataError
On Sun, May 19, 2013 at 6:37 PM, Kyaw Tun kyaw...@yathit.com wrote: Sorry for reposting again for http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0422.html Perhaps I am not well explain enough. In put and add method of object store and index, DataCloneError and DataError are immediately throw before executing IDBRequest. It seems good that exception are throw immediately, but in practical use case, these exception are in async workflow (inside transaction callback). Exception break the async workflow, (of course, it depending on usage design pattern). DataCloneError and DataError are preventable in most situation. But sometimes tricky. We even want database to handle these errors like database constraint. The logic will be much simpler if DataCloneError and DataError cause to invoke IDBRequest.onerror rather than exception. I can see where this might be desirable if arbitrary data is being used for values - for example, the key path yields an invalid key, or the value contains a non-cloneable member. From an implementation perspective, both must occur synchronously. The clone operation needs to determine the key and serialize the object at the time the call is made, otherwise the object could change. (As an implementation detail in Chrome at least, the data is thrown into another process when the call is made so it needs to be serialized anyway.) I seem to recall some discussion late last year about trying to make serialization asynchronous, to avoid main thread jank when passing data to Workers. The response was to make things transferable instead of serializing them. I can imagine an API where e.g. you could pass in a Typed Array and rather than being serialized synchronously it would have ownership transferred instead, then be serialized asynchronously but you'd still need to verify that the object was transferable up front so I'm not sure you'd gain anything in the error case.
Re: CfC: Shelve Web Intents, Web Intents Addendum, Pick Media Intent, Pick Contacts Intent, respond by 17 May (next Friday) (resend)
This CfC has completed with support for shelving the Web Intents Addendum, Pick Media Intent, and Pick Contacts Intent specifications. Based on the CfC mail discussion (and DAP teleconference) we have also agreed to publish Web Intents as a W3C WG Note to complete work (for now). As with all shelving (and Notes) the WG may decide to resume this work at any time with the current or a revised approach. Thanks to Jungkee for adding a note to the Pick Media Intent and Pick Contacts Intent specifications to mark them as shelved. I have done the same for the Web Intents Addendum. I have also updated the DAP home page to note that Web Intents Addendum, Pick Media Intent, and Pick Contacts Intent are shelved. We will go ahead to arrange the publication of Web Intents as a W3C Note and then I will update the DAP page accordingly. Thanks regards, Frederick Frederick Hirsch, Nokia Chair, W3C DAP Working Group On May 8, 2013, at 4:00 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote: (resend to include Web Intents TF list and WebApps list for shelving Web Intents spec, as well as DAP for all of specs) --- This is a Call for Consensus (CfC) to shelve the Web Intents, Web Intents Addendum, Pick Media Intent, and Pick Contacts Intent specifications (4 specs). Shelving in this case means that we are not sure the specifications will advance along the lines the drafts indicate. As a result we want to be clear to everyone that we may not advance the specifications or that we may change the approach. This does not mean that we have decided not to advance them, just that there is a question as to the direction and/or progression at this point. In order to advance this work we need support for the underlying technology, which we have been assuming will be a combination of Web Intents and Web Activities. This will require some sharing of proposals on the public list to enable progress. It would be best if we can progress this on the public list by September, so that we can have a meaningful result on the topic at a TPAC F2F. If we have consensus to shelve the documents, this will have the following immediate consequences: 1. The editors will edit each document to add a warning statement before the abstract. I suggest we use the following text (feel free to make suggestions): The Device APIs Working Group is currently not progressing the approach outlined in this draft. Please treat this document with caution and do not reference it or use it as the basis for implementation. The domain covered by this document is still within the scope of the Working Group as defined in its Charter. The Working Group may resume this work or adopt an alternative approach depending on the interest of WG members and implementers. 2. On the DAP home page we will move the specifications from the active roadmap [1] to the list of shelved specifications [2]. I suggest we keep both the links to the latest published draft and editors draft available when we do this. (I can volunteer to make this update if we agree to this CfC). Please send all comments regarding this CfC to the public-device-a...@w3.org mail list by 17 May (next Friday). Silence will be considered as agreement with the proposal. If you support this CfC, a positive response is preferred and encouraged, even if a +1. Obviously any constructive work on the list regarding the underlying technology would also be welcome. Thanks regards, Frederick Frederick Hirsch, Nokia Chair, W3C DAP Working Group [1] http://www.w3.org/2009/dap/#roadmap [2] http://www.w3.org/2009/dap/#shelved
Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement
On May 20, 2013, at 1:39 PM, Joshua Bell jsb...@google.com wrote: On Mon, May 20, 2013 at 6:37 AM, Ben Kelly bke...@mozilla.com wrote: On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote: IDBKeyRange.inList looks practically useful, but it can be achieve continue (continuePrimary) cursor iteration. Performance will be comparable except multiple round trip between js and database. I'm sorry, but I don't understand this bit. How do you envision getting the cursor in the first place here without a way to form a query based on an arbitrary key list? I'm sure I'm just missing an obvious part of the API here. Here's an example I whipped up: https://gist.github.com/inexorabletash/5613707 Thanks! Yes, I totally missed you could pass the next desired key to continue(). Unfortunately I don't think this approach would help much with the use case I am looking at. The round trips are significant and add up on this mobile platform. Also, it appears this would lose any parallelism from issuing multiple get() requests simultaneously. Querying by parallel multiple get in a single transaction should also be fast as well. Yes, Jonas Sicking did recommend a possible optimization for the multiple get() within a transaction. It would seem to me, however, that this will likely impose some cost on the general single get() case. It would be nice if the client had the ability to be explicit about their use case vs using a heuristic to infer it. In any case, I plan to prototype this in the next week or two. Thanks for taking this on - we'll be watching your implementation experience closely. :) Some discussion here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595 (That also links to a very raw document with other IDB v2 thoughts c/o a very informal google/moz brainstorming session.) One approach that adds generally useful primitives to IDB is (1) something akin to a key range that is a list of keys (per above) and (2) batch cursors that deliver up to N values at a time. Either of those is quite useful independently. The batch cursors do look useful. I had not run into that need yet since I am actually working with our prefixed getAll() implementation. Additionally IDBKeyRange.inList violate contiguous key range nature of IDBKeyRange. It is assumed in some use case, like checking a key in the key range or not. If this feature are to be implemented, it should not mess with IDBKeyRange, but directly handle by index batch request. Good point. I suppose an IDBKeySet or IDBKeyList type could be added. I'm not entirely convinced that's necessary. I don't believe we expose is in range in the platform currently, so exposing a new type to script seems excessive. On the other hand, range is a pretty well defined concept in general so it would be a shame to break it. I don't have a preference one way or another. I'm happy to implement a new type or not as long we can make non-consecutive key queries fast. Thanks again. I'll post back when I have the multi-get optimization prototyped out. Ben Ignoring deplicating keys is not a useful feature in query. In fact, I will like result be respective ordering of given key list. Well, I would prefer to respect ordering as well. I just assumed that people would prefer not to impose that on all calls. Perhaps the cases could be separated: IDBKeyList.inList([]) // unordered IDBKeyList.inOrderedList([]) // ordered I would be happy to include duplicate keys as well. Thanks again. Ben
Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement
On Mon, May 20, 2013 at 12:08 PM, Ben Kelly bke...@mozilla.com wrote: On May 20, 2013, at 1:39 PM, Joshua Bell jsb...@google.com wrote: On Mon, May 20, 2013 at 6:37 AM, Ben Kelly bke...@mozilla.com wrote: On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote: IDBKeyRange.inList looks practically useful, but it can be achieve continue (continuePrimary) cursor iteration. Performance will be comparable except multiple round trip between js and database. I'm sorry, but I don't understand this bit. How do you envision getting the cursor in the first place here without a way to form a query based on an arbitrary key list? I'm sure I'm just missing an obvious part of the API here. Here's an example I whipped up: https://gist.github.com/inexorabletash/5613707 Thanks! Yes, I totally missed you could pass the next desired key to continue(). Unfortunately I don't think this approach would help much with the use case I am looking at. The round trips are significant and add up on this mobile platform. Also, it appears this would lose any parallelism from issuing multiple get() requests simultaneously. Yep - which is what Kyaw mentioned above. (Performance will be comparable...). Just pointing it out for completeness. Querying by parallel multiple get in a single transaction should also be fast as well. Yes, Jonas Sicking did recommend a possible optimization for the multiple get() within a transaction. It would seem to me, however, that this will likely impose some cost on the general single get() case. It would be nice if the client had the ability to be explicit about their use case vs using a heuristic to infer it. In any case, I plan to prototype this in the next week or two. Thanks for taking this on - we'll be watching your implementation experience closely. :) Some discussion here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595 (That also links to a very raw document with other IDB v2 thoughts c/o a very informal google/moz brainstorming session.) One approach that adds generally useful primitives to IDB is (1) something akin to a key range that is a list of keys (per above) and (2) batch cursors that deliver up to N values at a time. Either of those is quite useful independently. The batch cursors do look useful. I had not run into that need yet since I am actually working with our prefixed getAll() implementation. Additionally IDBKeyRange.inList violate contiguous key range nature of IDBKeyRange. It is assumed in some use case, like checking a key in the key range or not. If this feature are to be implemented, it should not mess with IDBKeyRange, but directly handle by index batch request. Good point. I suppose an IDBKeySet or IDBKeyList type could be added. I'm not entirely convinced that's necessary. I don't believe we expose is in range in the platform currently, so exposing a new type to script seems excessive. On the other hand, range is a pretty well defined concept in general so it would be a shame to break it. I don't have a preference one way or another. I'm happy to implement a new type or not as long we can make non-consecutive key queries fast. Thanks again. I'll post back when I have the multi-get optimization prototyped out. Cool. Knowing what performance difference you see between multi-get and just a bunch of gets in parallel (for time to delivery of the last value) will be interesting. A multi-get of any sort should avoid a bunch of messaging overhead and excursions into script to deliver individual values, so it will almost certainly be faster, but I wonder how significantly the duration from first-get to last-success will differ. Ben Ignoring deplicating keys is not a useful feature in query. In fact, I will like result be respective ordering of given key list. Well, I would prefer to respect ordering as well. I just assumed that people would prefer not to impose that on all calls. Perhaps the cases could be separated: IDBKeyList.inList([]) // unordered IDBKeyList.inOrderedList([]) // ordered I would be happy to include duplicate keys as well. Thanks again. Ben
The JavaScript context of a custom element
Hello public-webapps, I have been following along with web components, and am really excited about the potential. However, I just realized that unlike the DOM and CSS, there is no real isolation for JavaScript in a custom element. In particular, the global scope is shared. This seems really unfortunate to me, and limits the ability of element authors to create robustly reusable components. I would like to suggest that custom elements have the ability to ask for a separate global scope for their JavaScript. This would be analogous to what happens today when you have multiple script-connected frames on the same origin. Has there been any thought along these lines in the past? Thanks, - a
Re: The JavaScript context of a custom element
Aren't ES6 modules is a good-enough solution for this issue? They make global collision rare and likely to be what the author really needed. jjb On Mon, May 20, 2013 at 1:00 PM, Aaron Boodman a...@google.com wrote: Hello public-webapps, I have been following along with web components, and am really excited about the potential. However, I just realized that unlike the DOM and CSS, there is no real isolation for JavaScript in a custom element. In particular, the global scope is shared. This seems really unfortunate to me, and limits the ability of element authors to create robustly reusable components. I would like to suggest that custom elements have the ability to ask for a separate global scope for their JavaScript. This would be analogous to what happens today when you have multiple script-connected frames on the same origin. Has there been any thought along these lines in the past? Thanks, - a
Re: The JavaScript context of a custom element
Custom elements have a closure to work in, as well as their own prototypes. I don't believe ES6 modules add much in this regard (possibly I'm missing something there). Separate global scope is a bigger issue. I believe there was general agreement to pursue (at some point) an otp-in 'isolated' mode for custom elements, where each element would have it's own global scope and access to a sealed version of the JS/DOM apis. Scott On Mon, May 20, 2013 at 1:26 PM, John J Barton johnjbar...@johnjbarton.comwrote: Aren't ES6 modules is a good-enough solution for this issue? They make global collision rare and likely to be what the author really needed. jjb On Mon, May 20, 2013 at 1:00 PM, Aaron Boodman a...@google.com wrote: Hello public-webapps, I have been following along with web components, and am really excited about the potential. However, I just realized that unlike the DOM and CSS, there is no real isolation for JavaScript in a custom element. In particular, the global scope is shared. This seems really unfortunate to me, and limits the ability of element authors to create robustly reusable components. I would like to suggest that custom elements have the ability to ask for a separate global scope for their JavaScript. This would be analogous to what happens today when you have multiple script-connected frames on the same origin. Has there been any thought along these lines in the past? Thanks, - a
Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement
Sorry, I always have problem with talking clearly.
Your experiment on this kind of problem is very interesting. I would like
to see what are optimal number of requests in a given transaction. These
two concepts (cursor walk and multi-request) can be employed together.
In my library implementation (ydn-db), multi-request is so commonly useful
that I had a pattern:
var b = db.branch('multi', false); // multiple request parallel
transaction thread
b.get('store1', key1);
b.get('store1', key2); // parallel request
b.get('store2', key1); // parallel transaction
b.values('store2', keyrange1); // parallel request on second tx
On the other hand, we do not want large batch request, because it will
consume large memory. Conservation of memory is more important than CPU for
mobile.
I am excited batch query are planning in v2
index.getAll(key_range, limit)
objectStore.getAll(key_range, limit)
A lot of optimization could be done with that api.
Regarding array key or key_range query, i think it is NOT very useful.
index.getAll(array_of_key_or_key_range, limit)
because we don't know result and respective query key.
Regarding prefix query, it is not very useful. It is trivial to create a
key range of desire prefix. Additionally we will also need start marker
key (as in aws s3 api), reverse order and limit. This method will destroy
current graceful api.
On Mon, May 20, 2013 at 9:37 PM, Ben Kelly bke...@mozilla.com wrote:
Thanks for the feedback!
On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote:
IDBKeyRange.inList looks practically useful, but it can be achieve
continue (continuePrimary) cursor iteration. Performance will be comparable
except multiple round trip between js and database.
I'm sorry, but I don't understand this bit. How do you envision getting
the cursor in the first place here without a way to form a query based on
an arbitrary key list? I'm sure I'm just missing an obvious part of the
API here.
Querying by parallel multiple get in a single transaction should also be
fast as well.
Yes, Jonas Sicking did recommend a possible optimization for the multiple
get() within a transaction. It would seem to me, however, that this will
likely impose some cost on the general single get() case. It would be nice
if the client had the ability to be explicit about their use case vs using
a heuristic to infer it.
In any case, I plan to prototype this in the next week or two.
Additionally IDBKeyRange.inList violate contiguous key range nature of
IDBKeyRange. It is assumed in some use case, like checking a key in the key
range or not. If this feature are to be implemented, it should not mess
with IDBKeyRange, but directly handle by index batch request.
Good point. I suppose an IDBKeySet or IDBKeyList type could be added.
Ignoring deplicating keys is not a useful feature in query. In fact, I
will like result be respective ordering of given key list.
Well, I would prefer to respect ordering as well. I just assumed that
people would prefer not to impose that on all calls. Perhaps the cases
could be separated:
IDBKeyList.inList([]) // unordered
IDBKeyList.inOrderedList([]) // ordered
I would be happy to include duplicate keys as well.
Thanks again.
Ben
