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

On Fri, Sep 12, 2008 at 10:36 AM, Marcos Caceres
<marcosscaceres@gmail.com> wrote:
> 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.

That's only if the widget is initially deployed from a source other
than the widget's home URL.  Even then, it's hardly rocket science, as
authors are, after all, software developers, and should be quite
familiar with the workings of their Web server.

But etags are a mature technology which has a lot of support in
existing, commonly used tools.  "description documents" are a new,
unproven (AFAIK) approach which will require new software be written.

> 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>

So you're using etags on the update, but not on the widget?!

>>> (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.

Perhaps they'd like to speak up.

Mark.

Received on Monday, 15 September 2008 13:30:47 UTC