Re: [Widgets 1.0] Automatic Updates (1.0)?

On 2007/08/31, at 4:27 PM, Marcos Caceres wrote:

> Hi Mark,
>
> On 8/30/07, Mark Nottingham <mnot@yahoo-inc.com> wrote:
>> You shouldn't need to extend HTTP at all for this use case; use the
>> URI, look at the ETag, Last-Modified, If-None-Match and If-Modified-
>> Since headers, along with the 304 response. Also, please recommend
>> that responses be cacheable for some reasonable amount of time (e.g.,
>> Cache-Control: max-age=3600).
>
> Good point. However, I need to investigate the implications (if any)
> of dynamically generated widgets and widgets sent over HTTPS. Do you
> see any potential issues? I'll try to write up a model based around
> Etags and related HTTP1.1 caching controls next week and see if there
> is any need for a separate spec for auto-updates at all. Regardless,
> given your knowledge of caching, any further input are appreciated.

Would be happen to help. WRT dynamic widgets and HTTPS, some use  
cases would help, but I don't see anything immediately.

>> Also, is the indirection of a manifest really necessary? Why not just
>> have them periodically poll the archive of the widget itself?
>
> Sorry, I don't understand what you mean by "the indirection of a
> manifest". Can you please explain what you mean by the above a bit
> more.

Just wondering why it's necessary to have a split between the widget  
and the metadata in the file (as per your example).

> Also, one cannot assume that a widget was always acquired directly
> from a web server: it might be the case that an end-user sends a
> widget to another end-user, say, over Bluetooth. Those widgets should
> still be able to connect back to their point origin and check if an
> update is needed.

I don't think that affects things, as long as the widget 'knows' what  
its URI is.

Cheers,

--
Mark Nottingham       mnot@yahoo-inc.com

Received on Thursday, 6 September 2007 03:31:49 UTC