On Sat, Oct 1, 2011 at 11:22 PM, Paul Ruizendaal <p...@planet.nl> wrote:
> ...Yes, and this is what any wrapper program can do. For example, there are > folks that would like to have Tcl/Jim with Fossil, I would prefer Javascript > (me, too, but don't tell anyone ;) Doing fork/exec sounds expensive, but on a posix box there is not much > difference between that and spawning a thread: > http://bulk.fefe.de/scalable-networking.pdf i wasn't aware of that. > Yes, and why would that be difficult to handle for a wrapper (see below)? > ...My questions was indeed the former: why do the calls to exit make it > difficult or impossible to chain commands -- there would simply be a chain > of CGI calls and if one step fails the wrapper has to decide what to do > next, just as it would have to do when a classic API call fails. > Implementing it as a wrapper hadn't occurred to me, actually. Yes, you're right - such a wrapper could simply call fossil in succession. i actually had a dream last night about a server mode which keeps a persistent connection for the JSON streams, but that isn't doable with the current architecture. > My question was not the latter ("why does it exit on exceptions"). Richard > calls it vintage unix thinking, but I think it is equally valid in a > RESTfull design -- perhaps any design. > In application design, yes, but not in a library design. i would immediately stop using any library which called exit(). Imagine if sqlite3 called exit when an insert failed. But your idea of a wrapper app would effectively turn fossil into a library of sorts, and would "hide" the exits from clients. -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
