Re: Widgets PAG seeks feedback on Widget Updates spec
Marcos Caceres a écrit : From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. ***Actually performing the update is left to the discretion of the widget user agent.*** JCD: this standards trick works if your aim is to have a patent on the highlighted point be judged as non-essential. There are a few points to check to ensure non-essentiality: - the language of the standard makes the feature a MAY (seems to be the case); - no test case uses the feature (should be easy too). However, if the implementations consistently implement the feature, they will infringe the patent and will get a call from the patent holder. It seems to me that this feature may end up as consistently implemented. There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? Best regards JC -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: Widgets PAG seeks feedback on Widget Updates spec
On Wed, Jul 15, 2009 at 1:54 PM, Jean-Claude Dufourdjean-claude.dufo...@telecom-paristech.fr wrote: Marcos Caceres a écrit : From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. **Actually performing the update is left to the discretion of the widget user agent.** JCD: this standards trick works if your aim is to have a patent on the highlighted point be judged as non-essential. There are a few points to check to ensure non-essentiality: - the language of the standard makes the feature a MAY (seems to be the case); - no test case uses the feature (should be easy too). However, if the implementations consistently implement the feature, they will infringe the patent and will get a call from the patent holder. It seems to me that this feature may end up as consistently implemented. There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? widget.update() will be dropped from the spec. It serves no useful purpose. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widgets PAG seeks feedback on Widget Updates spec
Dear Jean-Claude, On Jul 15, 2009, at 13:54 , Jean-Claude Dufourd wrote: Marcos Caceres a écrit : From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. **Actually performing the update is left to the discretion of the widget user agent.** JCD: this standards trick works if your aim is to have a patent on the highlighted point be judged as non-essential. It's not a trick, but more importantly you're answering the beginning of a thread that has now moved on to entirely different conclusions. There are a few points to check to ensure non-essentiality: - the language of the standard makes the feature a MAY (seems to be the case); But as you know variability in specification through optional features leads directly to a marked lack of interoperability. Therefore using a MAY here would be bad. Since anyway it was never the intent that an update occur when this method is called, and since an optional feature is by and large useless, this entire method has been dropped. This makes the point moot. - no test case uses the feature (should be easy too). Test cases are orthogonal since they are not normative. However, if the implementations consistently implement the feature, they will infringe the patent and will get a call from the patent holder. People are, of course, always free to infringe on any patent they wish. All we care about is that it is possible to implement in a sensible manner and without infringing. Given that we're dropping a feature that could look like self-updating but wasn't, this is a minor concern. It seems to me that this feature may end up as consistently implemented. If it is it won't be because of us since we've concluded that it's of little use and dropped it from the specification! There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? You seem to be mixing up Widget Updates and the update() method, is that the case? Also, the PAG has convened several times already and should produce its output in a timely manner. So yes the PAG has looked at the problem from a variety of angles (on which I won't comment since its operation is member-only) and when its conclusions are published they will be announced here. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Widgets PAG seeks feedback on Widget Updates spec
Dear Robin, Thanks for your email. Robin Berjon a écrit : There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? You seem to be mixing up Widget Updates and the update() method, is that the case? JCD: I understood the widget.update() method being discussed to be the scripted version of the Widget Updates mechanism. Please tell me if I am wrong. The current draft seems to still say that. And I am really not sure that a script-triggered version of the update mechanism can be discarded off-hand. Best regards JC PS: test sequences may be informative, but their content defines what is tested for normative behavior, so if a feature is tested in a sequence, it will appear normative to lawyers, even if the text of the spec says otherwise. -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: Widgets PAG seeks feedback on Widget Updates spec
On 7/15/09 5:56 PM, Jean-Claude Dufourd wrote: Dear Robin, Thanks for your email. Robin Berjon a écrit : There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? You seem to be mixing up Widget Updates and the update() method, is that the case? JCD: I understood the widget.update() method being discussed to be the scripted version of the Widget Updates mechanism. No. Read the spec. It says it's just a way of checking if an update is available (by asking the UA to check) and _not_ a way for a widget to update itself. Apples and oranges, as they say! (no pun intended) Please tell me if I am wrong. The current draft seems to still say that. You are wrong. The current draft does not specify anything normative about the behavior of widget.update(). And I am really not sure that a script-triggered version of the update There has _NEVER_ been a script-triggered version of the update or any such functionality specified by the Working Group. To imply otherwise is misleading. mechanism can be discarded off-hand. Yes it can: I discarded it from the spec. The point is moot. The issue has been resolved. Widget.update() does not exist (and has absolutely nothing to do with the PAG or whatever: widget.update was deemed useless by the Working Group long ago. We've just been too busy to publish a new draft without widget.update()). So, please stop bringing up this closed issue. As the Working Group awaits the findings of the PAG on how to proceed with Widget Updates, I find it inappropriate that you continue to discuss this matter here. Once the PAG findings are made public, and the WG has a chance to respond and act, then, if you have concerns, raise them here. Kind regards, Marcos
Re: Widgets PAG seeks feedback on Widget Updates spec
Hey Marcos, On Jun 30, 2009, at 11:24 , Marcos Caceres wrote: The purpose of widget.update() is/was _not_ to update the widget in any meaningful way: (...) In other words, it was/is a means to for a widget to ask the Widget User Agent if an update is available from the remote location addressed by the update element's href attribute (so, really it should have been called checkForUpdate() or updateInfo = new UpdateChecker(), which the example begins to elude to). As it says in the spec, _actually performing the update is left to the discretion of the widget user agent._ Thanks for the clarification. This however does not strike me as something that is vitally useful. Is there really a strong use case backing this? I'd much rather see updates entirely handled by the UA (with or without the sulphurous smell coming from Apple when one mentions this topic) as they are generally in a better position to handle this correctly (from within the UA context we'd have to handle the fact that it might clash with access, that the response isn't boolean, etc. and people would likely get that wrong, were they to use this feature). -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Widgets PAG seeks feedback on Widget Updates spec
On Jul 6, 2009, at 16:07 , Marcos Caceres wrote: On 7/6/09 3:35 PM, Robin Berjon wrote: On Jun 30, 2009, at 11:24 , Marcos Caceres wrote: The purpose of widget.update() is/was _not_ to update the widget in any meaningful way: (...) In other words, it was/is a means to for a widget to ask the Widget User Agent if an update is available from the remote location addressed by the update element's href attribute (so, really it should have been called checkForUpdate() or updateInfo = new UpdateChecker(), which the example begins to elude to). As it says in the spec, _actually performing the update is left to the discretion of the widget user agent._ Thanks for the clarification. This however does not strike me as something that is vitally useful. What's this? Sorry, by this I mean the ability for a widget to check if there exists a new version of itself. I can see value in the UA doing that on its own, at intervals and criteria (not if I'm roaming, more often if it crashed recently, etc) that can be set by the user. The UA would then provide a consistent UI indicating that an update is available and getting permission from the user (or just doing it, if allowed to do so). The value in allowing authors to add blink color='red'Update!/ blink seems rather limited to me, is what I'm saying. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Widgets PAG seeks feedback on Widget Updates spec
On 7/6/09 4:47 PM, Robin Berjon wrote: On Jul 6, 2009, at 16:07 , Marcos Caceres wrote: On 7/6/09 3:35 PM, Robin Berjon wrote: On Jun 30, 2009, at 11:24 , Marcos Caceres wrote: The purpose of widget.update() is/was _not_ to update the widget in any meaningful way: (...) In other words, it was/is a means to for a widget to ask the Widget User Agent if an update is available from the remote location addressed by the update element's href attribute (so, really it should have been called checkForUpdate() or updateInfo = new UpdateChecker(), which the example begins to elude to). As it says in the spec, _actually performing the update is left to the discretion of the widget user agent._ Thanks for the clarification. This however does not strike me as something that is vitally useful. What's this? Sorry, by this I mean the ability for a widget to check if there exists a new version of itself. I can see value in the UA doing that on its own, at intervals and criteria (not if I'm roaming, more often if it crashed recently, etc) that can be set by the user. The UA would then provide a consistent UI indicating that an update is available and getting permission from the user (or just doing it, if allowed to do so). The value in allowing authors to add blink color='red'Update!/blink seems rather limited to me, is what I'm saying. Ok, I'm with you now. Yes, I agree it's a bit useless. Besides, the same thing can be easily done with XHR if need be. I say we kill checkForUpdate() as it gives back no useful info.
Re: Widgets PAG seeks feedback on Widget Updates spec
On Mon, Jun 29, 2009 at 10:46 PM, Robin Berjonro...@berjon.com wrote: Hi, sorry, I hadn't seen that this was also posted publicly. On Jun 29, 2009, at 20:23 , Arthur Barstow wrote: The current Widgets-update Specification http://dev.w3.org/2006/waf/widgets-updates/ contains in 12.3 a description on how a widget could update itself by a javascript calling the widget.update() method I wanted to know how important this feature is to the group and how likely it will be that it will find widespread use. The goal is to assess whether it is worthwhile to circumvent the patent also for this self-update feature, which will be a little bit harder than the circumvention for the rest of the Specification. My personal and non-legal opinion on this topic is that that feature simply does not exist. It is mentioned in an example which by definition is not normative (section 1 Conformance further notes Everything in this specification is normative except for diagrams, examples, notes and sections marked as informative and the section itself starts with This section is informative.) It is not defined by Widget Updates and it is not defined by Widget APIs and Events. Furthermore my understanding is that this is the only part of the specification that could possibly infringe Apple's patent, which means that the specification in fact doesn't since that feature is not a part of it (or any other). We can more than very easily drop the example, and in fact the entire section since it is entirely incorrect. The purpose of widget.update() is/was _not_ to update the widget in any meaningful way: From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. **Actually performing the update is left to the discretion of the widget user agent.** In other words, it was/is a means to for a widget to ask the Widget User Agent if an update is available from the remote location addressed by the update element's href attribute (so, really it should have been called checkForUpdate() or updateInfo = new UpdateChecker(), which the example begins to elude to). As it says in the spec, _actually performing the update is left to the discretion of the widget user agent._ So, to try to be crystal clear, here is how I thought this would work wrt widget.update() when I created this thing (and more or less what is eluded to in the spec): 1. Widget is running. 2. At some point in time, widget calls widget.update(callBackFunction). (Note that this is just one of the three strategies for _checking for the availability of an update_ (no actual updating is performed) - other two strategies are handled exclusively by the widget user agent, see spec). 3. Iff an update element is declared in the widget's config doc, and has a valid href attribute, the Widget User Agent MAY check for changes in the update description document (using http responses AND checking the content of the UDD for changes). 4. If an update is available invoke callBackFunction with an object describing the update. 5. If no update is available, invoke callBackFunction with an object describing that no update is available. 6. Author notifies, via some modality (e.g., a sound, an alert, or some visual means left up to the author), that an update is or is not available for the widget. 7. The end user quits the widget. 8. The end user requests from the Widget User Agent to update the widget (if update is available). 9. The widget user agent downloads the updated package from the location identified by the description document. 10. The widget user agent checks authenticity of package. If everything is ok, then overrides the existing widget, but maintains preference data. User agent MAY notify the end user that the widget has been updated. 11. End-User restarts the widget. So, I don't what would be achieved by removing widget.update() as it doesn't actually do any updating. If anything, we need to redefine widget.update() to make it more useful and powerful. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widgets PAG seeks feedback on Widget Updates spec
Hi, sorry, I hadn't seen that this was also posted publicly. On Jun 29, 2009, at 20:23 , Arthur Barstow wrote: The current Widgets-update Specification http://dev.w3.org/2006/waf/widgets-updates/ contains in 12.3 a description on how a widget could update itself by a javascript calling the widget.update() method I wanted to know how important this feature is to the group and how likely it will be that it will find widespread use. The goal is to assess whether it is worthwhile to circumvent the patent also for this self-update feature, which will be a little bit harder than the circumvention for the rest of the Specification. My personal and non-legal opinion on this topic is that that feature simply does not exist. It is mentioned in an example which by definition is not normative (section 1 Conformance further notes Everything in this specification is normative except for diagrams, examples, notes and sections marked as informative and the section itself starts with This section is informative.) It is not defined by Widget Updates and it is not defined by Widget APIs and Events. Furthermore my understanding is that this is the only part of the specification that could possibly infringe Apple's patent, which means that the specification in fact doesn't since that feature is not a part of it (or any other). We can more than very easily drop the example, and in fact the entire section since it is entirely incorrect. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
