RE: DAV-Enabled field (was RE: A case for GETSRC)

><<
>              (2) "Once the software is written, the dual-URI space is both
>superior and cost-free."  It is confusing to users when they
>configure their DAV client software, and providing support is
>expensive.
>>>
>I don't think anyone went so far as to say it's "cost-free".

Ok, I exaggerated.  But I think the point is still a good one.  Even 
if the implementation is cheap, support can still be very expensive. 
Hence the need for a single URI space from the user's point of view.

><<
>Put yourself in the shoes of the administrator of a University's
>faculty web pages server trying to provide DAV access to their pages.
>Let's say there are about 1200 faculty at your school, and only 1/4
>of them have web pages but only update them a couple times a year.
>That's about 300 phone calls and emails you are going to get twice a
>year asking why they can't get the SSI version of the such-and-such
>page or why they can't "log in with Dreamweaver" to their web page.
>(Reminder: these people are too "smart" to RTFM.)
>
>With this crowd, it would be way easier to just serve the source to
>DAV clients (subject to the proper authentication of course) and
>avoid a lot of these support incidents.  None of them care about
>using DAV on display documents at all.
>>>
>Right... it's probably no worse than the current situation with FTP,
>but if you can improve on the current situation , it can create new
>opportunities.  In this case it would save money for the support
>staff at the university.

Right.  Only DAV is already much better than FTP even without 
DAV:source.  You have arbitrary properties (which many users find 
useful over time) and Locking.  I'm a big fan of locks.

>People have pointed out that the mapping from display URI to
>source URI can be any number of functions.  This has been
>viewed as a feature because it allows the server implementer
>to use whatever mapping makes most sense to him. But that flexibility
>causes complications for a UI that wants to simulate a single URI
>space.

Not just complications in the UI, but also complications for the 
server administrator and for plug-ins trying to stay out of each 
others' way, and configuring security realms that are DAV-specific 
and largely duplications/variations of permissions elsewhere in the 
URI space.

A lot of our customers are beginning web masters.  They want a 
product the works easily "out-of-the-box" and is easy to support. 
They also want something that will grow with them.  Hence our desire 
to provide a simple default configuration (DAV-as-file-system with no 
funny business with the URI space) AND the opportunities for a "real" 
configuration that uses DAV:source and maps two spaces together, etc..


>The client UI doesn't know enough to easily figure out what
>the mapping function is so it can have trouble supporting a MOVE
>operation that looks like a MOVE in a single URI space.  (At
>least that's my current understanding.  I haven't
>thought about Eric's posting long enough to be sure.)

I think it can just ask about the source URI of the destination 
(unless that destination doesn't exist - then what?)

>I'm wondering now if the DAV:source property definition can be
>constrained so that a client can trivially know how the two
>namespaces map to each other so that it can know how to do a
>MOVE in the output URI space and simulate a single URI space.

That's an interesting idea.

cjh

--

Received on Tuesday, 5 March 2002 12:59:17 UTC