Infoworld: WebDAV Comes of Age

=?iso-8859-1?B?SvZzaA==?= josh@bluescreen.org
Wed, 24 Oct 2001 00:45:52 -0400


> Justin said:
>
> This is one thing I've always wondered about MS' updates to it's
> system call API.
>
> Why haven't they kept the old "backwards compatibility" APIs in sync, and
> capable of doing the wonderful new stuff that the new APIs can do?
>
> It all seems to downright encourage third-party app breakage.
>
Im not quite sure i read you right.  Im assuming you are saying:
"Why didnt MSFT make the existing APIs apps use for file access
work with DAV in the first place.   What they did amounts to adding
new 'secret' APIs that break 3rd  party apps or make them not support
new things like MSFT apps do.."

I'd disagree with that assertion.  The initial DAV implementation
was done on the team I was program manager for, so i can
shed some light on why we did what we did.

Our goal was to include some scenarios like web-file save and
being able to manage a web site like a local disk.  The prime examples
were an explorer view like "start c:\" but for a website, and for
apps like office to be able to save a doc to a website.

We analyzed our options.  The main two were:
1)APIs to support a DAV URI as a file argument, we didnt actually think
of the drive mapping shortcut that XP uses.
2) Implement a shell/namespace extension to support DAV in the same
 way that FTP was supported for IE.

#1 Would have been the best long term solution as it would make all apps
"just work" with DAV.  However downsides were
1) We were the IE/Wininet team (we do the protocol handlers for IE)
The teams that control the lower level stuff are not under our control.
We could not convince them to remove something out of their already
full schedule for their next release to work on our suggestion.

2) we couldnt think of a way to make the standard file i//o calls support
URI's without creating a huge potential for incompatibility.  Changing
exising APIs is extremely difficult without breaking backwards compat.
Early versions of MSHTML, MSXML and ADO are prime examples
of incompatibilities inadvertantly created by changing the way an existing
API worked, or deviating from what app developers "expected to happen"
Even simple stuff breaks, if you change the allowed characters in a string.
Many apps had hard coded string verifiers that would catch a ":", multiple
"."
or other stuff that would be legal and required to support a URI.
It was just too risky.  In fact, this is more likely to break 3rd party
apps, which is LESS serious than having the 3rd party app not
automatically gaining the new functionality.
These days, versioned components are common for this reason.
If you want to parse an XML document with the final W3C XSLT
and Xpath specs with MSXML 4.0, you must create an XMLDocument.4.0
instead of just XMLDocument, there are too many incompatibilities that
can pop up breaking apps.  It is naive to say "then just test better
to make sure there are no incompatibilities"  We used to assume
we could do that, unknown permuations over time have taught us
that we cannot.

3) we didnt have the expertise to do the work ourselves.
We arent the kernel team, we're at the shell/IE level.

4) we would have had to implement it twice.  Once as a real
NT kernel driver/service/whatever and once as some sort
of VXD for win9x, which was even HARDER to figure out.
Doing the NT version was much cleaner, but would not hit
the majority of the IE user base.  the win9x version would
have been very much a hack, that would have been thrown out
over time.

The namespace extension had these benefits:
1) could be implemented in our team, and on the schedule for IE
2) would not affect any existing apps that didnt use the latest common
controls (the file dialogs that support network places) and would not
break anything.
This is the surest way to get cut from a product release; not being
able to assert backward compat.  If you break something, god forbid
like AOL or Real, we'd be strung up by our gonads.
3) did not require mucking with very serious code that we didnt have
expertise with.
4) Did not require an upgrade to the OS to get functionality.

It had these downsides:
1) did not cover all apps
2) only worked for high level shell operations, eg
cant do a seek on it like a file stream natively
3)Didnt work as efficiently as a "real" redirector would.

Overall, our plan was to get some DAV functionality out there.
Other 3rf party apps who were on track to use the new common
controls, independent of IE, would get the benefit.
The near term solution was do the namespace extension, cover both
win9x and NT with one stone.  Long term, the redirector implementation
would happen later, with the convergence of NT and win9x.
(Dont forget that at the time, win98 was to be the last win9x release)

So, we basically weighed the costs from and schedule, resource and risk
perspective and the right thing to do was the namespace extension for the
immediate solution followed by the later long term redirector solution.
I still think this was the right decision.
We probably could have done a better job of evangelizing the way
to support DAV via common controls.

I'd also like to say that backwards compatibility and providing
new functionality for existing apps are two different things.
Backwards compatibility, which is REQUIRED, means that
old apps run just as they did, same features, same bugs (many programs
make use of bugs as features and depend on them).
Its IMPOSSIBLE to test every app, and in this example,
adding the URI support to fopen() would put apps
in situations where we couldnt predict exactly what would happen.
The best way to avoid this is to isolate new features so that
old apps never end up in these situations.
Basically it means we dont break them.

Adding new functionality to old apps is a much riskier proposition.
Its prone to incompatibilities and risks breakage of 3rd party apps.
Even the XP redirector solution shows that while we could mold
DAV into a drive mount model, we couldnt just make fopen()
support a URI, that would break too many things.
These days, I've come to accept that often enough, new apps
that are made to use the new versions of COM objects that
have new functionality will get new those new features.
Old apps will generally not.

So, in a way, backwards compat and making old apps get the
new functionality is often dependent on mutually exclusive goals.


> --j.
>
>