- From: Amelia A Lewis <alewis@tibco.com>
- Date: 09 Jul 2002 13:59:18 -0400
- To: Mike Dierken <mike@dataconcert.com>
- Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
On Tue, 2002-07-09 at 13:26, Mike Dierken wrote:
> > From: Amelia A Lewis [mailto:alewis@tibco.com]
> > Incidentally, URIs also typically suggest a strongly
> > client-server model, a pull model, and synchronous
> > interactions. All of those may be good reasons to speculate
> > on how to extend URIs, or what good addressing semantics are
> > for asynchronous, or push, or strongly peer-to-peer models.
> >
> I disagree about URIs implying a pull model and synchronous interactions.
> The mailto:mike@dataconcert.com URI isn't pull and it isn't synchronous.
Hmm. Yes. I'm wrong. But that's an awfully interesting URI.
It isn't GETtable. It's non-idempotent. It's POST-only, and the action
won't generate or return a representation of the resource created, since
that (whether it's imap://mike@mail.dataconcert.com/INBOX (does imap
have message identifiers as fragments?) or some other representation)
isn't of interest to the sender. Sending with subject or body content
of getStockQuote('TIBX') may generate an additional resource, but it
isn't associated with the original URI (it might create a resource via
mailto:alewis@tibco.com, which would in turn create another imap
resource). Interesting because, even though the content is idempotent,
the activity is non-idempotent, creating two additional resources, one
for request and one for response.
Awfully SOAPy, really. Or SOAPy pre-web-method.
It isn't possible to identify URIs that are only GETtable, only
POSTable, or any other characteristic, is it? Except by knowledge of
the application that actually handles the URI?
Amy!
--
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Tuesday, 9 July 2002 13:59:39 UTC