- From: CJ Holmes <cholmes@4d.com>
- Date: Tue, 5 Mar 2002 10:04:21 -0800
- To: DAV <w3c-dist-auth@w3.org>
- Message-Id: <a05101401b8aab6c0a0e4@[10.0.1.20]>
><< > (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