[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Indicate entry in Collection Feed is full representation
- To: "Brian Smith" <brian@xxxxxxxxxxxxxx>
- Subject: Re: Indicate entry in Collection Feed is full representation
- From: "Teo Hui Ming" <teohuiming.work@xxxxxxxxx>
- Date: Sat, 1 Dec 2007 09:03:54 +0800
- Cc: atom-protocol <atom-protocol@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=u/+rAHnszJpnE11agjqNrWuZlJJUuwTzkvgF2jFelQ4=; b=he2y2Z160pf+n0Ya/r1qFnNzkdETemfSOC/BtQ2l6/vTx1hRSEGulNt3sEtzJdtf7koipPTXbOgcNGTP0VN/r7Uxo8zC+HLsAV1gNXkyxDsHR0VQMo7mwzK41gr3YcTeFmamCD2zqaXbYauJqtrIhwnIUGy81nvzia0cShqC39E=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NqkAN8DBmExCrv8Qv5m3Z59D9xF/3k+5RE32ikOFpM4GPFsI6BTlMDJFEqo+5/4QUJe4v1CR2Uu5GPsgt/R9PsEc0pRXLcX/l2h6ei3/sZSR1zEjQMEVz0TiGb6kPkn9qEg7v9MwRRiHgsTdV2iP5X4cHHcXZ/NYeNkBmF9AFzI=
- In-reply-to: <>
- List-archive: <http://www.imc.org/atom-protocol/mail-archive/>
- List-id: <atom-protocol.imc.org>
- List-unsubscribe: <mailto:atom-protocol-request@imc.org?body=unsubscribe>
- References: <73ec599d0711300312o6c22fc76q91787bb4b7d8f6d@xxxxxxxxxxxxxx> <>
- Sender: owner-atom-protocol@xxxxxxxxxxxx
On Dec 1, 2007 12:47 AM, Brian Smith <brian@xxxxxxxxxxxxxx> wrote:
> Problem 1: The entry in the feed might have been up-to-date at the time the feed was generated, but is now out of date. As discussed in previous threads, clients should not expect the feed to be updated immediately each time an entry is added or updated. In particular, a "Cache-Control: max-age=120" on the feed would be totally reasonable for many applications.
I agree. This is actually the reason to embed an etag in the <entry> element.
Since my entry data is light-weight, it's fine to include full
representation entries in the feed. When a client wish to edit an
entry, the le:etag becomes useful as the client can use it to send a
conditional GET to validate whether the entry is up-to-date, if not
valid, the server simply returns an updated copy. If valid, the client
will just process the <entry> element in the feed, since it is a full
representation. That's my intention.
> Problem 2: The presence of the le:etag attribute does not mean that the entry in the feed is equivalent to the entry retrievable from the link with that attribute.
You're right. I'm curious about the initial use case of le:etag.
Consider to place it in any atom:link. If a client hasn't dereferenced
the link, it will not obtain a copy of the representation, so it is
unlikely the client would send a conditional GET (or other conditional
operations). If a client has dereferenced the link, it would already
obtain the etag directly from HTTP ETag header. Interestingly, the
le:etag is not used in both situation.
> No, it just means that the entry resource has not changed since the link with the le:etag attribute was made. It doesn't say anything about the entry that contains that link.
I find le:etag usable only when it appears in the "edit" link of a
full representation <entry> in a collection feed, possibly hinting the
<entry> element is *the entity* represented by the particular
entity-tag. I probably miss the point. Is there a reasonable use case
to place an le:etag in the "edit" link of an partial <entry> in a
feed?
> Another mechanism would be needed.
What if by adding an element to explicitly declare the <entry> element
in a feed is a full representation, E.g.:
<feed>
<entry>
<title>foo</title>
<link rel="edit" href=".."/>
<content>light-weight data</content>
<x:complete etag="xyyz"/>
..
</entry>
</feed>
Does it work for common case?
Thanks,
--
Teo Hui Ming