From: Jim Whitehead (firstname.lastname@example.org)
Date: Tue May 30 2000 - 09:18:51 PDT
> why clutter up a simple, beautiful
> protocol when you could build same functionality on top of base
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.
> Ask yourself: why integrate DAV support into the client apps, instead
> of integrating into the filesystem directly? The only reasons I can
> think of are (a) increase sales by pushing MS own "DAV enabled" apps, or
> (b) they're just plain stupid, not as innovative as they think. I can't
> believe (b) so it must be (a.)
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.
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.
The other issue for DAV filesystem support is temporary (or "turd") files.
When you open a Word document, a temporary file is created. Same thing for
Emacs. For a non-integrated application, those temp files would be saved
across the network, instead of on the local machine, which is the best
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.
This archive was generated by hypermail 2b29 : Tue May 30 2000 - 09:24:24 PDT