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

At 01:25 AM 2002-11-03, Mark Nottingham wrote:

> > It might just be a matter of educating people what is already possible.
>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.  Consider the Grid Notification Framework and its
concept of soft state for something which is low cost but does not
promise eternal perfection.


For infosets where you don't know the time of the next change and the change
is unlikely or infrequent, you use a combination of leave-no-traces pull and
subscription push.  You write your code depending on the RFC *and* you
subscribe to STD1 to know when you need to iterate.

The message is not "this dataset is good forever" but rather "for change
notification subscribe to this (could be RSS) push service."

A simple "this is valid forever" bit is low-cost, and high risk.  It is
saving cost in a domain of distributed computation where prices are still
falling precipitously, and leaves the user holding risk that is not.

We need to be evolving in the direction of burning more computational cost
and reducing the risks arising from human error.  Moore's law is leaving the
human intelligence the only scarce resource in the system.

[letting the work follow the mobile professional]

"Rick Stevens - Fast Forward to the Year 2008" in

The shock at the latter meeting was that it revealed the weak link in the
assumptions of the pending broadband revolution [which has indeed
collapsed].  It is the stubbornly high cost of screen pixels.  We can't just
drown the user in full-motion 3D video because even 'though the network
bandwidth is cheap, the screen bandwidth is not.  So discovering what memes
are operative in the recognition processes of the user, and projecting into
a [personally tailored] space compacted using these elements is still going
to be necessary for the foreseeable future.  Gives lots of scope to Intel
and Cisco to pump up the ops and bit-miles available to the engines that
select, project, and present the user's personal view of the process.

Just in the future the 'select' and 'present' will be on a client node[1] and
the merge/project will be upstream, at a portal or "on the Grid."  You will
drag a web page[2] or portlet fragment thereof onto the portal page and it
will fold/sift right into your personal problem-attack discipline.


[1] Strictly speaking, within the user's sphere of firm control, possibly
separated from the "portal or Grid" processes by a network hop.  In other
words this could be on a consumer-affine-group portal and be discovering
the portlets in portal pages from originator-affine-group portals.

[2] Of course this is not a run-of-the-mill web page of today.  But it's 
not that
far off, either.  What it takes is roughly the server-side intelligence 
already present
in "authoring systems for device independence" of which several good ones were
briefed at the W3C Workshop on Device Independence Authoring Techniques


and the back-link-to-source that is discussed in the Recommendation 
covering XSL FO.


> > The other day the RSS world discovered ETags and it seems to have
> > spread around various implementations quite quickly, after some
> > people wrote it up clearly and others became motivated enough by
> > the bandwidth savings to spend time implementing it.
>Saw that; very encouraging.

Received on Sunday, 3 November 2002 14:32:31 UTC