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

Hi Mark,
On Mon, Sep 15, 2008 at 2:22 PM, Mark Baker <distobj@acm.org> wrote:
> 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.
>

I don't think we share the same definition of  "software developer".
Having taught web development for 5 years at a university level, I can
tell you right now from professional experience that computer science
students or software engineers or graphic designers or interaction
designers have limited, if any, understanding of HTTP beyond typing
"http://" into a browser and, on a _really good day_, how GET and POST
work (that might be because I'm a crap teacher, but I doubt it). This
situation has only gotten worst with the advent of CMSs that take all
the complexity out of web development. This is not to say HTTP is hard
or that developers are stupid, but that the HTTP layer works so well
that it can often be ignored with little consequence.

And, although I agree that HTTP on its own gives us most of what we
need to do the updates, an author should not have to be a "software
developer" in HTTP in order to have their widgets updated.

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

I respectfully disagree; description documents are somewhat common
today. Get your local proxy to debug any "check for updates"  call in
most applications and you will find something that resembles the
update model we are proposing (see, in particular, Firefox, Firefox
Add-ons and Konfabulator... Opera also makes use of XML files, as does
iTunes I believe). Also, OMA-DL, which closely resembles our widget
update format has been widely implemented and is in use today in the
mobile space.

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

Yes. The widget can come from any source, not just HTTP. You might be
misunderstanding what a widget package is.

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

I hope so too... but they are a quiet bunch who don't like to repeat
themselves (and, regrettably, probably don't follow this list anyway).
However, their opinions about this model were clearly voiced at the
last F2F when they supported the publication of this model as a FPWD.
For me, that says pretty clearly that they are in support of it.

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

Received on Wednesday, 17 September 2008 13:51:20 UTC