- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Mon, 17 Sep 2007 13:46:04 +1000
- To: "Jon Ferraiolo" <jferrai@us.ibm.com>
- Cc: "public-appformats@w3.org" <public-appformats@w3.org>
- Message-ID: <b21a10670709162046s48503bc9vaee74460336b12ef@mail.gmail.com>
Hi Jon On 9/14/07, Jon Ferraiolo <jferrai@us.ibm.com> wrote: > > Hi everyone, > After thinking about this for a few weeks, my opinion is that the Widgets > 1.0 specification should steer clear of features around automatic updates. > The first-order issue is just getting the industry to work towards a unified > approach to achieve a write-once, run-anywhere benefit such that widget > developers can produce a component that will work across many different > platforms. IMO, automatic update is in the area of nice-to-have features > (bells&whistles) and makes more sense in a second technology wave after the > first wave has achieved some momentum in the industry. > I've personally received numerous off-line requests for automatic updates (AUs), particularly from enterprise users. I don't think AUs are "bells and whistles", and my position is that it should be a fundamental part of widgets: eg. If I discover that my widget is not interoperable with platform X, then I can put out an automatic update to address that problem; hence AUs will help with "write-once run-anywhere" model you describe. To not have a model for AUs impoverishes the Widgets 1.0 [1] work compared to current solutions. Also, if widgets are to leverage HTML/CSS/JavaScript as the UI language, then all the cross-platform issues associated with HTML come as baggage (because, most of the time, widget user agents will leverage browsers that don't fully interoperate). Those problems cannot be solved by this working group (hence we have HTML5). The best WAF can do is recommend a set of technologies to implementers that will meet the requirements desired by vendors and users [2]. > Instead, it is more advisable to wait for some of the early-adopter > gorillas to implement and deliver a simple widgets standard and let them > make progress on de facto standards for automatic update and then (down the > road) attempt to codify into a standard the technology approaches that have > proven to work. > Hence we have looked at FireFox's Addons and Yahoo!'s Widget Engine's update models. As far as I can tell, Firefox's solution has been stable for a number of years. If my assumptions are wrong, then please send me some pointers. If there are other HTTP-based solution I should be researching, please let me know. There are likely to be various complexities around automatic update that > will only become apparent when operating in the real world contexts. The > thrust of the Widgets effort should be to produce a standard that is as > simple as possible in order to accelerate industry adoption. > I agree in as far as you are talking about a separation of concerns: widgets and a general model for AUs. I'm willing to develop and edit the AUs model separate from the Widgets 1.0 specification (which is what I proposed at the start of this thread). Widgets can then use AUs independently of the Widgets 1.0 Specification and Widget User Agents may support an Automatic Updates Specification. I personally don't like that solution because I think all Widgets User Agents should support AUs, but I could live with it. > In fact, I would drop the ZIP packaging from version 1 and auto-discovery > features, also. Most likely, the "less is more" approach is likely to have > the best chance for success. > A while ago you suggested WAF use OCF as the widget packaging format [3] . We have adapted much of widgets 1.0 specification around the Zip conformance requirements listed in OCF [4]. Now you are suggesting we drop Zip all together? The Widgets 1.0 Spec definition of a widget: "Widgets are a class of client-side web application for displaying and/or updating local or remote data, packaged in a way to allow a single download and installation on a client machine or device." Widgets 1.0's definition of a widget explicitly calls for packaging. Please explain what constitutes a widget without a package? How do I send you my unpackaged widget, say, over Bluetooth to a friend? > Over in my world (OpenAjax Alliance), there is a lot of discussion about > mashups. There is clearly a major technical overlap between installable > desktop widgets and mashup components. I would expect that widget developers > would like to produce a single component that works within both widget > engines and mashup engines. As a case in point, there are paths by which > Google Gadgets can work within mashup environments (e.g., IBM's > QEDwiki/Info2.0) and within Google Desktop. I haven't seen evidence that the > Widgets 1.0 effort is taking mashup scenarios into account sufficiently. > This brings us full circle back to automatic update. There are likely to be > some update complexities if a widget has to go through the mashup container > for various proxy services. > In technical terms, please define exactly what a "mashup" is and please use a real example that relies on a web browser (eg. Mash-up information from where a book was published from Amazon's dataset with Google maps or something similar). Also, can you explain what a "mushup component" is in the same technical terms? I ask you to do this for two reasons: Firstly, the WAF community needs to comprehend what the OpenAjax Alliance understands a mashup and component to be (By technical terms, I mean a list of RFCs or W3C Specs, or Software, or Scripting languages that are involved in this "mashup" process, and exactly what role they play in "mashing up" the data on the client-side). Secondly, define exactly what technologies/requirements are not currently listed by either the Widgets 1.0 Specification or the Widgets 1.0Requirements document to achieve a "mashup". If we are not meeting some particular business use case, WAF needs to clearly understand why and how? I've had exactly this issue raised by another member of the OpenAjax Alliance community; however, he was unable to provide me with any of the technical detail we need. Hopefully you can enlighten us. > But all of this discussion of features isn't as important as which > companies are on board with this effort. Which vendors have committed to > implement Widgets 1.0? Are Microsoft, Apple, Google and Yahoo involved? > Has Nokia committed to implemeting this spec? If the big guys don't > implement Widgets 1.0, then the widget developers will focus on the > formats that the big guys use instead of Widgets 1.0. > > Last time I looked all the mayor players were part of WAF. However, I think it is premature to be asking vendors to commit to something that is in its infancy. I would expect that once the Widgets 1.0 Spec reaches CR, then vendors may choose to opt-in if the specification meets their business needs. Before any of this can happen, we need a solid spec that vendors can see real business value in and that solves real problems. Kind regards, Marcos [1] http://www.w3.org/TR/widgets/ [2] http://www.w3.org/TR/widgets-reqs/ [3] http://lists.w3.org/Archives/Public/public-appformats/2006Dec/0131.html [4] http://www.idpf.org/ocf/ocf1.0/index.htm -- Marcos Caceres http://datadriven.com.au
Received on Monday, 17 September 2007 03:46:12 UTC