Gerry, you mentioned not wanting revisions to be a "second-class citizen" in the web api.  What are some user stories that concern you?  Any solutions to propose?

Not sure what I meant then, but thinking about it now, I'm thinking in terms of REST collection semantics. When you name a card, the action would be "index" on the collection of revisions, which can be defined to give current. New revisions are 'POST'ed, and DELETE and PUT are not generally supported.

In terms of this ticket, the creation of the card is really necessary for it to get revisions. Hard to see how you have members of a collection (revisions) without the collection being instantiated. On the other hand, 'trashed' cards hold their revisions, so maybe this is the same thing as that.

  --Gerry Gleason.....Wed Jan 04 20:41:54 -0800 2012

hmm, the real need is to be able to save drafts before a card is saved. it seems like there are two choices: save a revision with no card, or save a card that is in some sort of not-yet-legitimately-saved state. The latter actually makes me a lot more nervous, especially since some of these cards have no name.

The proposed API does actually have an answer to your REST concerns. The collection is the group of all unsaved cards, and the card "*draft" essentially holds the space for the collection.

  --Ethan McCutchen.....Wed Jan 04 21:03:49 -0800 2012

I'm not sure I understand the *draft solution. I might want to use that for the case of saving a draft before the user has filled in the name, but I think it might be better to catch that case in javascript (i.e. warn the user to give the card a name so drafts may be saved).

If you 'pre-create' the card with the name and type (if specified already), then you can do the same with plus-cards for the multi-create case.

  --Gerry Gleason.....Thu Jan 05 02:50:30 -0800 2012

If you pre-create the card, how do you handle it when two people save drafts of a card with the same name but different types?

Of course, the counter there is that if it's only in revisions, how do you store the name or the type at all? And I guess long term we really need to store some type info in revisions to be able to do true rollbacks. OK, fine, bastard. You're probably right.

I think our experience with trash is making me trigger shy here. Although things have settled down recently, the "trash" feature has been one of the most challenging features of wagn, because it's a card that's not a card, which makes for a lot of special case handling. Of course, our fetching and WQL mechanisms should do away with most of that now, but it still makes me nervous.

I think I would prefer that we have some solution for saving drafts of blank cards. That feels like a perfectly acceptable work flow to me -- plop in some content, figure out the name later. Would be nice if that were safe.

btw, we could also be thinking about whether we want to integrate some local (cookie-based?) draft-saving. Might be able to do something more granular locally, but it would have to be complementary. I wouldn't want to give up the remote draft saving -- bails you out of browser crashes.

  --Ethan McCutchen.....Thu Jan 05 07:52:43 -0800 2012