Future resources

We're getting off-topic here, but you raise an important point that I'd
like to respond to.

On Tue, Feb 18, 2003 at 11:28:10PM -0500, Geoff Arnold wrote:
> It's worse than that,

BTW, to Chris' response, that knowledge he speaks of is no different
than the knowledge required to know that turnOn() is implemented, or
that "1" means "on" and "0" means "off".  The win is in the common
PUT method, instead of the cornucopia of turnOn(), switchOn(), on(),
foofoo(), etc.. methods.

> because of composition. Consider the composite
> action "PlugInNewLightbulb THEN TurnOnLightbulb". Not only do we have
> to handle partial failures; one cannot even *express* the desired state
> of the new bulb as a state-representation PUT, because it doesn't exist
> until the first part of the action is complete.

Not at all.  The bulb doesn't have to be chosen to have a URI.  I could
mint a URI that identifies "the bulb that will be chosen during
PlugInNewLightbulb", long before its chosen, without any trouble.  It
does, after all, have identity.

The URI would likely resolve to 404 at mint-time, and 301 once a URI for
the less indirect reference to the light bulb is known.  There's no
problem with this.  Indeed, it's a key feature of the architecture,
since to require otherwise is to ban 404s and require some degree of
centralized control, as some previous (long-forgotten) hypertext systems
did.

Unfortunately, while this topic is very relevant to the TAG's
architecture document, it's probably irrelevant to ours, unless of
course we adopt REST. 8-) So I suggest we take this off-line, perhaps to
www-talk.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Wednesday, 19 February 2003 00:34:38 UTC