Re: Yet another example of Microsoft Evil

Date view Thread view Subject view Author view

From: Jeff Bone (
Date: Tue May 30 2000 - 11:32:55 PDT

Jim Whitehead wrote:

> > why clutter up a simple, beautiful
> > protocol when you could build same functionality on top of base
> > protocol?
> When I think of HTTP, two words that do not come to my mind are simple and
> beautiful. Have you ever looked deeply into HTTP caching? Ick. Or how
> about the existence of spelling errors in the protocol elements? Geesh.
> Then there is Basic authentication, oy.

Yeah, yeah, yeah. And creat() should've been called create(), too, but that
didn't stop UNIX from being beautiful in a big picture sense. The value of any
platform technology is proportional to the number of interconnections between {
people, components, whatever } it enables [Hans Reiser] --- and HTTP certainly
facilitates those kinds of connections in a big way. So, simple: just about
anybody can grok HTTP; beautiful, in global effect if not in execution.

> Like most things, the reality is far more nuanced. Where Web Folders was
> developed had much to do with when the DAV standard was finished compared to
> the code complete dates for Office/IE/Windows. It also has much to do with
> the groups that pro-DAV people within Microsoft belonged to, and hence could
> gather resources within. DAV support in Office was a very close thing, not
> at all a foregone conclusion at the time.

Yeah, yeah, yeah. But the evil empire theory is just too good. ;-)

> I have heard of some work towards creating a full-featured DAV filesystem
> plug-in for Windows. I think this would provide a nice, medium-quality
> integration layer for the many applications that will never be DAV-enabled.
> But, for the best support, DAV should be integrated into applications, and
> those applications should be aware they are performing operations across the
> network. Ask yourself, how often do you employ the network access icon (the
> spinning "e" or "N" in the upper right hand corner) of your browser? The
> purpose of this user interface element is to provide visibility into the
> network behavior of the application. Network file system interfaces have
> traditionally acted to hide the network access, and this leads to user
> applications behaving strangely, with little feedback to the user about what
> network activity could be causing the behavior.

While this is true, I don't agree with the proposition that all things remote
should be explicitly remote. A little transparency goes a long way; if the
platform is robust enough, it should be possible to preserve 80% or so of the
user-level semantics even though the underlying semantics and failure modes are
quite different from the local case. And that's enough. After all, failure is
just that --- failure. While you should design for it, it shouldn't be assumed
to be the overriding mode. Good failure detection, reporting, and recovery
capabilities are a better option IMO than just throwing up one's hands and
saying "well, hell, remote is never going to be like local so let's just forget
about transparency altogether."

BTW, I'm not claiming that this is what you're advocating. However, I've seen a
disturbing trend over the last few years in distributed systems research *away*
from transparency. To wit: Java RMI. I know the reasons, and I know they're
good --- but one would think that, esp. -w- respect to research efforts and tech
that breaks new ground, we'd be pushing the edge forward.

This retrograde trend is even more unnerving when you realize that disconnected
operation of intermittently connected mobile devices is equivalent to operation
of a statically connected device partitioned due to failure from some resource
it wants to use. Location transparency and failure tolerance have always been
important attributes of networked systems, and IMO will become even moreso.

> If you're interested in seeing what an HTTP filesystem would really be like,
> try out Ufo or WebOS. I did once, and they were kinda pokey.

Have looked extensively at the WebOS stuff, haven't checked out Ufo. Thanks!

> - Jim


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue May 30 2000 - 11:38:12 PDT