incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <mikeal.rog...@gmail.com>
Subject Re: Proposal for changes in view server/protocol
Date Sun, 01 Aug 2010 18:56:08 GMT
No, that's not enough.

You want to handle the error, you want the ability to return an HTTP forward
to a show function if the update is successful OR to a newly generated
"success" page.

These are pretty standard HTTP form semantics and they can't be handled with
a single function in a nice way.

Also, your proposal doesn't have a good way to propagate the update error
back to the error page which is essential.

This is the kind of thing most modern web framework provide a simple high
level abstraction for. We don't need the high level thing but we do need a
good API that binds a particular "update" to all the HTTP and related
database calls it needs to make. Without that nobody can even build the high
level thing.

-Mikeal

On Sun, Aug 1, 2010 at 11:48 AM, J Chris Anderson <jchris@apache.org> wrote:

>
> On Aug 1, 2010, at 11:46 AM, Mikeal Rogers wrote:
>
> > I've been thinking about this a lot lately and I'm starting to think
> > that continuing to build on the update function isn't the best idea.
> >
> > The update function just wasn't designed with this in mind.
> >
>
> I don't get it, this seems a perfectly sensible enhancement to the current
> API. All that is missing is the ability to not spew garbage to the user on
> failure conditions.
>
> > Any way I can think of to add support for this use case to the update
> > function ends with a API I wouldn't actually want to use. Meanwhile, for
> > simpler cases the update function is still one of my favorite APIs and I
> > don't like the idea of complicating it.
> >
> > Maybe it's best here to design a new API called "form" or something
> similar.
> > We could build in the standard redirect system and failure cases and make
> > the API really nice to use and just leave update alone.
> >
> > Thoughts?
> >
> > -Mikeal
> >
> > On Sun, Aug 1, 2010 at 11:38 AM, J Chris Anderson <jchris@apache.org>
> wrote:
> >
> >>
> >> On Aug 1, 2010, at 11:34 AM, Jason Smith wrote:
> >>
> >>> On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <jchris@gmail.com>
> wrote:
> >>>
> >>>> I'm totally +1 on getting rid of these rough edges. I seriously doubt
> >> I'll
> >>>> have time to do anything but cheerlead, so if this is gonna happen,
> >> someone
> >>>> is gonna have to take up the charge.
> >>>>
> >>>
> >>> Do you mind a little discussion about how that might work?
> >>>
> >>> It seems to me there is no avoiding round trips between the _update
> >> function
> >>> and couchdb.
> >>>
> >>> Is it allowed for the update function to query couchdb about whether id
> X
> >> is
> >>> available?
> >>>
> >>> Is it allowed (or preferred) for the update function to have an
> >> additional
> >>> flag similar to rereduce, indicating it is being called again due to a
> >> bad
> >>> _id? What about two bad _ids in a row? Is the function called
> >> indefinitely
> >>> with a growing list of previously-bad _ids until it returns an
> >> already-seen
> >>> bad _id, in which case you get a 409? None of this strikes me as clean.
> >>>
> >>> Another thing to consider is perhaps the _update function can just
> >> specify
> >>> what to render in the case of conflict and let the client handle it. I
> >> think
> >>> that would be sufficient to at least allow a basic HTML form workflow
> >> again.
> >>>
> >>
> >> I like this the best. It could return:
> >>
> >> {
> >> "success": "<p>it worked</p>",
> >> "conflict" : "<p>sorry, out of date rev made an update conflict, please
> >> reload and retry</p>",
> >> "error" : "<p>yikes, I don't know what went wrong</p>"
> >> }
> >>
> >> and if any are missing you get the CouchDB json response instead
> >>
> >>> --
> >>> Jason Smith
> >>> Couchio Hosting
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message