Hi,
Thank you for the response.

On 3/23/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
>
> 2006/3/23, Toru Marumoto <[EMAIL PROTECTED]>:
> > Questions:
> >     *If I PUT to Member URI, status code 201 is returned. Fine.
>
> No, within the APP, PUT is used to update an existing member, not to
> create a new one, so a successful PUT will return a 200 or 204.

Sorry, that's a typo. I meant "status code 2xx is returned".

> > What about the body? Does the response body always have an Atom
> > entry document or not?
>
> No. The response is kind of "it succeeds", not "it succeeds and here's
> the new resource representation". The response body could very well be
> an HTML document saying "Yeeh ah! You got it!", or it could be an Atom
> entry with basically the same content, or it may be the Atom entry
> representation of the resource (those two Atom representations can be
> distinguished by their respective atom:id), or it may be the HTML
> representation of the resource (provided it has one), etc.

Thank you for clarifying this for me.
Then I've got no choice but to always ignore the response body(of PUT and POST)
since you aren't sure what format of the body would be returned.
The samples in the spec kind of confuse me.

> > Feature Request:
> >     *Client Sync (query entries undated since yyyy/mm/ddThh:nn:ssZ ,
> >      or HTTP HEAD to a member uri to find out if entry is modified, etc)
>
> PaceOrderCollectionsByAppModified provided a really simple way of
> sync'ing but was rejected for a "YAGNI" reason (You Ain't Gonna Need
> It).
> http://intertwingly.net/wiki/pie/PaceOrderCollectionsByAppModified
>

I was thinking more like a using "Range: Header" in the PaceSliceAndDice3.

Ok, here is the situation. I have developed a blog client a couple years
ago, and now kind of popular here in Japan. It's got a couple of thousands
(or more) users. [end of shameless plug]
The requests I get most these days are sync'ing and moving. I get these
requests from the users almost twice in a week.

People use a blog client at work *and* at home. Naturally, they want Sync'ing
feature since no one wants to override he/she just wrote a while ago at
different PC. It's not good idea to retrive all entries and go through them
everytime a user launch a client application.
So, I think sync'ing is a very impotant feature.

Reply via email to