On Fri, Sep 9, 2011 at 7:42 PM, Stephan Beal <[email protected]> wrote:
> On Fri, Sep 9, 2011 at 7:11 PM, Ron Wilson <[email protected]> wrote: > >> Also, I agree that HTTP status codes should be for transport rather >> than application errors. >> > > :-D. Okay, so there's 2 votes for that. > > In my experience (and i've written boatloads of JS- and Java-based Ajax the > past 2 years), i find it more intuitive to write code where i have a clear > separation of transport-vs-app errors. > To stress this point a bit using a real-world example, please take a look at: http://whiki.wanderinghorse.net Poke around the wiki there - the content's not important, just try the various buttons, the editor, and whatnot. Try swapping between pages while editing (by following wiki links, NOT using the browser back button!). And keep in mind that that site's UI is 100% JavaScript/HTML/CSS and the data is 100% JSON served by a CGI. Even the wiki rendering is done on the client. i think that app would have been more troublesome to code if i had had to be able to distinguish REST-style HTTP errors from "real" HTTP errors. The overall goal of this effort is that that type of thing can be done for fossil. -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
