[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AtomPubIssuesList for 2005/02/22


Ezra Cooper wrote:
On 2/24/05 4:53 PM, "Robert Sayre" <mint@xxxxxxxxxxxxxxx> wrote: 

I guess it depends how many simple resources, categories, and users you
have.


I don't see any reason why these things couldn't have "updated" properties,
making them easier to fetch in chunks; but I didn't want to require it.


I would say they have a Last-Modified property.


Ezra's proposal includes a depth header. I don't see a restriction on
circular references.



Here my intention was that "Depth: infinity" would just give me everything
that is a descendant of this collection--with no repeats. I'll revise it to
be more clear on that point. I'm not sure that circular references are bad.

"Descendant" is meaningless in your Pace. Clients will either implement the equivalent of a garbage collector, or just drop repeats all together. My bet is on the latter. Might as well specify it.


But is MOVE going to be part of Atom? Let's suppose not, for the moment. If
a server then wants to support WebDAV fully, there's no reason it can't
restrict its own URIs in this way, and support MOVE. If it's not doing MOVE,
then what's the point of restricting it?

To include MOVE, a la carte, within Atom, seems like feature creep to me.



Atom, the protocol that can't rename a jpg ;)

The second point is that half the reason
WebDAV has the restrictions it does is so that clients can expect a
server to act the same.


Expect the server to act the same in what way?

When you post something, you have a rough idea where it will end up.


"Free" URIs look sort of like XSS attacks to me.


I don't see any risk here. Can you explain?

Go ahead and DELETE something from server A because Server B said it was OK and knows what collections on Server A would also have a member removed? I guess...



The third point is that there is still no use case for URI freedom,
while the restriction has many.



I can see use cases for WebDAV, as you've outlined, but not for the URI
restriction per se. Fewer spec'd restrictions should mean that we're
compatible with more things, not fewer. It still seems as though
WebDAV-savvy implementations could be a compatible extension on top of the
APP core--and we wouldn't have to place needless restrictions.

Am I missing the insight that would explain how spec-restricted URIs would
enable something?


It wouldn't enable anything if you want to restrict the protocol to exactly the capablilities in your Pace. I think your Pace is premature simplification :).


URI freedom would be more interesting if
you could remove an entry from one collections without removing it from
all collections (LINK/UNLINK).



I'm afraid I don't know the spec you're referring to here; can you give a
reference?


RFC2068 (the first cut of HTTP 1.1)

http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2068.html#sec-19.6.1


4. """If no Range: HTTP header is given in the request, the interval is taken
  to be all of time."""


Most servers will probably just throw an error. Secondly, it's not a
Range. I don't know what it is, but it's something else. There's no
unit, and there's no total.



Do you mean, "not including a Range header" is not a Range? Seems true
enough. Do you want to see something changed?

No, I mean the proposed range spec is not a range. It's just a query, I guess.

Oh, how do I get a list of my Drafts?

Robert Sayre