- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 30 Oct 1996 21:29:29 -0800
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
I wanted comment on these ideas before I did anything with them. Note that the following contains very rough drafts. Thanks, Yaron New Content-Range types. Currently, Content-Range only allows one to specify byte ranges. However there are often situations where one would like to be able to specify a page, a paragraph, or other arbitrary entity. It would be nice to be able to request the fourth page of an entity. Of course the request may not always be meaningful or the token type used in the request may not be understood by the server, but I do not believe that is a big deal. The spec for the header would be something like: Content-Range = "Content-Range" ":" content-range-spec content-range-spec = byte-content-range-spec | token-jump byte-content-range-spec = bytes-unit SP first-byte-pos "-" last-byte-pos "/" entity-length entity-length = 1*DIGIT token-jump = jump-type number-jumps jump-type = token number-jumps = 1*DIGIT A jump-type could be "Paragraph", "Page", or whatever. The number-jumps specifies which jump-type to set, retrieve, whatever. There are some truly ugly semantics here, for example, what if one PUTs a "Page 3" but the content is so long it leaks into "Page 4"? Is this a legal put? The problem would have to be dealt with on a jump-type by jump-type basis. The document Judith sent out contained the following section: RETENTION SCHEDULE / ARCHIVING / BACKUP / RESTORE Create schedule for deletion based on any of the following: last accessed date author any catalog value or set of catalog values manual selection Monitor deletions Audit deletions Notify based on schedule for deletion Move infrequently used materials to alternative storage locations or devices Automatically Transparent to online users Configurable Configurable archiving Evaluate for archiving based on: authors, creation date, document type, keywords, last edit date, retention date, any catalog value Incremental and full backups Scheduled backups or manually initiated backups Restore specific data or files from backup Do we want to put support for these features into the standard? By supporting these items I mean moving the responsibility for ordering the events from the client to the server. We could add a delay header: Delay-Header = "DelayHeader" ":" HTTP-date I can hear the thoughts in the heads of several of you saying "But wait, we need a repeat header so we can say things like copy files to these URLs every Thursday of the month for the next year." This is known as scheduling and is a rat whole so deep that entire conferences have been lost inside of it. Trust me, you would rather send 12 DelayHeaders. I realize that DMA is about as popular as an Electro Magnetic Pulse but someone (read: NOT ME) should really go through the DMA spec, http://www.aiim.org/dma/spec75/index.html, and see how well we measure up. Currently there is no way to delete the contents of a directory. A directory is really just a sitemap file which allows one to group various unrelated URIs together. However if one were to want to delete all the URIs in the directory one would have to send delete requests for each URI. The logic extends if one wants to delete a directory and all its sub directories. One of the reasons for this behavior is that many of the common container commands, such as copy and move, have no meaning in this context. If I have a container with URLs foo/bar and bar/foo then the only way to copy them is to specify for each one where they are to go. If I order "copy foo/bar and bar/foo to foobar" what does this mean? However delete and undelete are different, they have a very obvious meaning in the context of our containers. Should we add headers in the mime-type for delete, undelete, and destroy to allow the command to be applied to the contents of a directory in a possibly recursive manner?
Received on Thursday, 31 October 1996 00:29:28 UTC