Infoworld: WebDAV Comes of Age

Mike Dierken mike@DataChannel.com
Wed, 24 Oct 2001 10:10:23 -0700


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15CAE.C44BEE60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Great background.
I came to the same conclusion about namespace extension .vs. =
file-system
driver when doing this kind of stuff at DataChannel. It was more =
important
to deliver the value to users in certain apps and find out if it even =
made
sense for people than it was to enable the feature in all apps. That =
was
what we figured would happen. We hooked into Office apps via a new menu =
item
and did the file transfer via some COM code that did XML over HTTP.

And given the headaches with writing just a namespace extension, I'm =
glad we
didn't try to do the file system driver. I think Aventail did something
similar, but they had the skills to do the file system/network =
redirector.
Don't know if they ever released it.


mike

> -----Original Message-----
> From: J=F6sh [mailto:josh@bluescreen.org]
> Sent: Tuesday, October 23, 2001 9:46 PM
> To: Justin Mason
> Cc: Mike Dierken; FoRK@xent.com
> Subject: Re: Infoworld: WebDAV Comes of Age=20
>=20
>=20
> > 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"=20
> 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.."
>=20
> 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.
>=20
> 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.
>=20
> We analyzed our options.  The main two were:
> 1)APIs to support a DAV URI as a file argument, we didnt=20
> 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.
>=20
> #1 Would have been the best long term solution as it would=20
> 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=20
> 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.
>=20
> 2) we couldnt think of a way to make the standard file i//o=20
> 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=20
> way an existing
> API worked, or deviating from what app developers "expected to =
happen"
> Even simple stuff breaks, if you change the allowed=20
> characters in a string.
> Many apps had hard coded string verifiers that would catch a=20
> ":", 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=20
> 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.
>=20
> 3) we didnt have the expertise to do the work ourselves.
> We arent the kernel team, we're at the shell/IE level.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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)
>=20
> So, we basically weighed the costs from and schedule,=20
> resource and risk
> perspective and the right thing to do was the namespace=20
> extension for the
> immediate solution followed by the later long term redirector=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> So, in a way, backwards compat and making old apps get the
> new functionality is often dependent on mutually exclusive goals.
>=20
>=20
> > --j.
> >
> >
>=20

------_=_NextPart_001_01C15CAE.C44BEE60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



RE: Infoworld: WebDAV Comes of Age 



Great background.
I came to the same conclusion about namespace = extension .vs. file-system driver when doing this kind of stuff at = DataChannel. It was more important to deliver the value to users in = certain apps and find out if it even made sense for people than it was = to enable the feature in all apps. That was what we figured would = happen. We hooked into Office apps via a new menu item and did the file = transfer via some COM code that did XML over HTTP.

And given the headaches with writing just a namespace = extension, I'm glad we didn't try to do the file system driver. I think = Aventail did something similar, but they had the skills to do the file = system/network redirector. Don't know if they ever released = it.


mike

> -----Original Message-----
> From: J=F6sh [mailto:josh@bluescreen.org]
> Sent: Tuesday, October 23, 2001 9:46 PM
> To: Justin Mason
> Cc: Mike Dierken; FoRK@xent.com
> Subject: Re: Infoworld: WebDAV Comes of Age =
>
>
> > 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.
> >
> >
>

------_=_NextPart_001_01C15CAE.C44BEE60--