Re: MailDAV

Date view Thread view Subject view Author view

From: Mark Baker (
Date: Wed Mar 15 2000 - 23:25:07 PST

There's only so many hours in a day, so I'm going to trim this down

At 11:07 PM 3/15/00 -0600, Jeff Bone wrote:
>sets up with the original design of HTTP? What's wrong with something like
>OR, if you like this better
> with <methodCall> ... in body?

>> You don't *need* RPC.
>Oh, get off the name semantics. I'm talking RPC in some very abstract
manner ---
>RPC as an *application* of HTTP. And yes, I very much believe I *do* need
to be
>able to invoke code somewhere else to do something besides spit me back a
piece of
>static HTML. I don't want to just say "give me the state of X." I want
--- need
>--- to parameterize requests. Query strings, POST bodies, whatever.

[ pay attention to this one! 8-) ]

You don't *NEED* to do any such thing!!! It's all freaking equivalent!!
The only question is whether it's *efficient* for a broad problem domain.

>I am happy with HTTP --- as is, pre-DAV. Let's see if I can frame the
>HTTP is a combination of two things: a wireline protocol for "requesting
>resources" combined with a global, loosely-coupled naming scheme based on
>Okay, fine, that lets me identify my server objects and request that they
>me *something.*

A representation of their state.

>I'm quite happy with the response, if it's some MIME body --- oh,
>say, XML data. Still, I need to parameterize those requests --- and the
>seems to need that as well.

GET is the request. What do you need to parameterize?

>> But is it worth the cost of breaking the Web's architecture? What exactly
>> will it mean to cache a method invocation? What will it mean to try to
>> transcode one?
>Aw, geez. How does this break the Web's architecture? Caching? Bullshit.
>Surely it is --- and should be --- up to a given resource to define caching
>policies. Do I cache method results? No, of course not. But that's already
>accomodated, without much pain or controversy, in the existing architecture.

You're not caching that "document" because it doesn't make sense to, not
because the content itself is updated very frequently. *BIG* difference.

>Ah, but my point --- insisting upon HTTP as being about a particular
domain of
>resources --- call them "documents" --- is an academic viewpoint almost
>disjoint from the reality of today's Web.

Not at all. The *VAST* majority of web applications out there are Good.
Off the top of my head, the only bad ones are those than tunnel other
protocols through POST; XML-RPC/SOAP, RealAudio/Video, etc..

>So, we have three camps AFAICT:
>Mark: HTTP-believer, hypertext purist
>Adam: HTTP-nonbeliever, protocol-per-app enthusiast
>Jeff: HTTP-abuser, protocol antagonist, "I just want to build apps"
>Oh, well. Anyone want to make an idea futures claim on which of these
will turn
>out to be the winning position in the long term?

We've been at it in a big way for 5+ years, and there's a clear winner
right now. I'll let my bet ride.


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 23:41:04 PST