Re: [widgets] <update> death of the etag attr

Hi Mark,

On Fri, Sep 12, 2008 at 3:19 PM, Mark Baker <distobj@acm.org> wrote:
> Hi Marcos,
>
> On Fri, Sep 12, 2008 at 5:46 AM, Marcos Caceres
> <marcosscaceres@gmail.com> wrote:
>>
>> Hi All,
>> I've dropped the etag attribute from the <update> element in the
>> Widget Packaging spec as I deemed it too difficult to use in practice
>
> How so?

It requires authors to debug HTTP to get at the etag. Then they need
to put that etag into the widget config doc. This is a pain with
little value. The download description documents are very light weight
and authors can simply not put a download document on their servers
till they are ready for widget engines to update their widgets (i.e.
return at 404).

So we are claer, I make a widget called "foo.wgt". I send it out to
the world via "widgetgal.com". I put the following into my widget
config:

<widget ...>
  <update uri="http://a.com/v1/u.xml"/>
</widget>

Then, when the  widget user agent tries to get at u.xml, it either
gets a 404, or a 200. Once a 200 is received (and hence u.xml), then
the widget engine can cache that response and simply monitor the etag
or the modification date (304).

u.xml would look something like:

HTTP/1.1 200 OK
Date: Tue, 27 May 2008 06:02:05 GMT
Content-Type: text/xml
Content-Length: 370
Etag: a3aaa33a

<?xml version="1.0" encoding="utf-8"?>
<widgetupdate xmlns="http://www.w3.org/ns/widgets"
  src="https://a.com/myWidget/v1.1b/awesome.wgt"
  notify="https://a.com/myWidget/updateManager.php"
  version="1.1 beta (awesome edition)"
  bytes="1024">
  <details href="http://a.com/myWidget/1.1/whatsnew">
    We fixed some bugs and added some new APIs!
  </details>
</widgetupdate>


>> (and mostly redundant). It is also unnecessary as updates will be
>> handled through Update Description Documents as defined in the Updates
>> spec (and not by pointing to widget packages on the Web). I will try
>> to have the Update spec ready for FPWD by the end of today.
>
> That seems a tad overengineered to me.  Have implementors bought into
> it?  It seems to me that the etag solution is the low hanging fruit
> here.

I can't say that implementer have bought into it. But I can say that
none have raised objections to the current proposal. The model was
presented to a number of potential implementers at our F2F in Turin.


-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 12 September 2008 14:37:03 UTC