W3C home > Mailing lists > Public > www-talk@w3.org > November to December 2002

Re: drag and drop portlets [was Re: resource immutability (is eventually false)]

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 3 Nov 2002 10:44:36 -0800
Message-ID: <01c001c28369$0f4bb620$f4457743@mnotlaptop>
To: "Gerald Oskoboiny" <gerald@w3.org>, "Al Gilman" <asgilman@iamdigex.net>
Cc: <www-talk@w3.org>

> >I was thinking of something that would allow lower-cost
implementations;
> >right now, if a tool wants to take advantage of such information, it
needs
> >to implement a complete, HTTP-compliant cache. An immutable flag would
> >lower the bar considerably; it says "yes, just store a local copy and
use
> >it from now on."
>
> The only problem with this is that it is an exercise in denial.
>
> The overriding reality is that the only invariant is change.
>
> Under reasonable assumptions, the 'immutable' bit is, with probability
one,
> eventually false.  What saves us is that eventually we are all dead; one
> could say we don't care about the time after the bit goes invalid.  But
that
> is not clear in practice.
>
> Simply defining an 'immutable' bit would result in too many deadlocks
where
> the clients are counting on the saved copies of what the author had
thought
> would never change while the author is by now aware of errors in that
file
> that need to be corrected.
>
> Unless you have a push channel bearing anti-messages that
> can force-flush the bad data, the system should not support such
> rash language.

Of course; it's communicated by changing the URI. The channel is
application-specific.


> Consider the Grid Notification Framework and its
> concept of soft state for something which is low cost but does not
> promise eternal perfection.

Thanks, I'll add that to the collection. Notification/invalidation is a
very popular topic for research and specification, but as of yet I haven't
seen much wide (Internet-scale) deployment.

Some others:
http://www.hpl.hp.com/techreports/1999/HPL-1999-109.html
http://www.globecom.net/ietf/draft/draft-reddy-enp-protocol-00.html
http://www.alternic.org/drafts/drafts-d-e/draft-danli-wrec-wcip-00.html
http://ftp.ics.uci.edu/pub/ietf/notify/
http://www.w3.org/TR/esi-invp
http://www.mnot.net/papers/draft-nottingham-webi-warm-00.txt
http://internet.conveyor.com/RESTwiki/moin.cgi/NotificationQueuing

I suspect that notification/invalidation fails in Internet deployment for
the same reason that Web proxy caching has so many problems; it expects
entities with no trust relationship to commit resources to each other, and
to honor a contract without any means of verification.

In any case, this doesn't address the problem at hand, because
invalidation is an optimisation to caching that increases, not decreases,
implementation complexity and opportunity for error.
Received on Sunday, 3 November 2002 13:45:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:27 GMT