Re: issue: draft posts

[Joe Gregorio <joe.gregorio@xxxxxxxxx>]

On Tue, 22 Mar 2005 11:10:52 -0500, Robert Sayre <mint@xxxxxxxxxxxxxxx> wrote:
> Joe Gregorio wrote:
> > On Tue, 22 Mar 2005 10:44:44 -0500, Robert Sayre <mint@xxxxxxxxxxxxxxx> wrote:
> >
> >>Dare Obasanjo wrote:
> > That is, all entries,
> > whether 'draft' or 'published', appear in the main entry
> > collection. In addition, there is a 'draft' entry collection
> > that contains only those entries that are drafts.
> >
> > My gmail account works in much the same way,
> 
> Ok, but how does GMail talk to the server? That's where the protocol is.

I have no idea, I just brought it up to point out that the 
idea of 'updating' something and having it move from 
one collection to another is common.

> >
> > I do worry that this could cause a raft of new entry collections
> > and make the protocol that much more complex.
> >
> > If you can't tell, I have no opinion yet, just exploring ideas.
> 
> Me too. I was suggesting two separate collections, rather than
> sub-collections. I can think of two possible ways to move between them:
> 
> MOVE /drafts/entryXYZ HTTP/1.1
> Target-Collection: /public
> 
> or...
> 
> POST /public HTTP/1.1
> With-Entry: /drafts/entryXYZ
> 
> This has the advantage of happening above-board. We could also GET and
> PUT to the entry resource with headers instead of shoving it into the
> body. I'm kind of worried we'll end up tunelling a bunch of RPC stuff in
> the pub: namespace.

I was thinking of a third way, by PUTing the Entry back with a new
value for 'atom:state'. If you changed 'atom:state' from 'draft' to
'publish' it would stop appearing in the drafts collection and start
appearing in the main collection. 

Ok, this just seems to be opening a can of worms. I think we should
just have the main entry collection. Once a client does a sync then
it should know which entries are drafts and can present that list 
quickly to the user. 

   -joe

-- 
Joe Gregorio        http://bitworking.org