RE: collection with ordered members

BTW we are also moving our repositories and other systems to RDBS.
Actually, getting the file system onto a DB has been a holy grail at MS
forever. I certainly don't want to stop what many of us see as the
inevitable outcome of this endeavor. More than that, we will be having a
WebDAV Search BOF at the December IETF where sort will be on the agenda.
I realize Jim was only asking for a single sort but a lot of folks need
arbitrary sort.

The reason for the fixation on file systems is that for some time to
come the majority of WebDAV servers are likely to be file system based.
As such we need to be sensitive to their needs and make sure we don't
craft a standard which is too onerous to implement. 

I think we need to keep the lesson of HTTP 1.0 in mind, it was, I
believe, such a success because it was so brain dead easy to implement.
I also think a lot about X500, which actually had a lot going for it,
but it was so mind blowingly complex that a very select group was
willing to implement it. It is all about finding the right balance. I
don't claim to know where that balance is, I can just do my best to
provide my opinion in the hopes of helping to find it.

I think that sorting is an important issue but it is one that I think is
more appropriately addressed in the WebDAV Search BOF than in the WebDAV
base spec. As the authors like to say "DAV is done when there is nothing
left to cut." =)

		Yaron

> -----Original Message-----
> From:	Fisher Mark [SMTP:FisherM@exch1.indy.tce.com]
> Sent:	Wednesday, October 29, 1997 9:33 AM
> To:	'Jim Davis'; 'Judith Slein'; Yaron Goland
> Cc:	w3c-dist-auth@w3.org; Jim Whitehead (E-mail)
> Subject:	RE: collection with ordered members 
> 
> >The promise to maintain order is a serious burden to implementers.
> Most
> DAV
> >servers will most likely be implemented on top of file systems,
> current
> file
> >systems do not maintain order so in to return the INDEX results in
> the
> >promised order the server has to read in the entire directory,
> keeping
> it in
> >local memory, sort according to the requested order, and then return
> it.
> >However, without having to worry about order the server can stream
> the
> >response as it reads it, never having to keep more memory around then
> what
> >is needed for a single entry.
> 
> I dunno, Yaron... We have 3 document management systems around here,
> with 2 on relational database systems and the 3rd (a Web system, our
> "Corporate Technical Memory" you may have heard me talk (email?)
> about)
> due to be switched mainly to a relational database system later this
> quarter.
> 
> >That is too much work and too much of a performance hit for a feature
> that
> >no one has ever found compelling enough to even bother implementing.
> >Remember, standards follow they do not lead. Given that this feature
> is
> no
> >widely implemented it is clearly experimental in nature and should be
> >explored using the experimental RFC mechanism, not thrown in to DAV
> where it
> >will cause implementers endless headaches.
> 
> I don't really see the problem, as the actual file data should be able
> to be cached (and I would think offhand the order should be too).  The
> caching software would need to know that these documents have an order
> to them.  You would likely need caching software specialized for DAV.
> 
> [...]
> >Anyway, it is 1:30 in the morning and I am going to sleep. I will be
> >happy to continue to participate in this thread once a draft has been
> >submitted.
> 
> I look forward to it.
> ==========================================================
> Mark Leighton Fisher          Thomson Consumer Electronics
> fisherm@indy.tce.com          Indianapolis, IN
> "Browser Torture Specialist, First Class"

Received on Wednesday, 29 October 1997 14:04:01 UTC