On 1 Oct 2011, at 15:28 , Stephan Beal wrote: > On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal <p...@planet.nl> wrote: > > Maybe you could do some http-over-stdin/stdout, and speak json there. :) > > Isn't "fossil cgi" already doing that? A front-end could build the > appropriate environment variables and fork/exec "fossil cgi", feeding the > post body to fossil's stdin. > > That is basically what server mode does - prepares the cgi environment > (including stdin/stdout) and runs it through CGI mode...
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 and I'm sure there are those who would like Python or PHP. In each of those environments it would be easy to add a command/library function that calls Fossil's json interface through exec'ing Fossil in cgi mode. Tcl etc. would be wrapped around Fossil, rather than Fossil wrapped around the language and that way everybody can have their preferred language without further bloat in the Fossil binary. 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 > (where output is very controlled (entirely buffered) because no body text may > be sent before the headers are sent). The majority of the parameter handling > in all of the fossil commands relies on the environment having a fresh state > for each request, which means the whole environment, GET, POST, and > everything, needs to be reconstructed before each commands. e.g. the way a > given command is invoked is based on the request path (an environment > variable), which can only be set to one value for any given invocation of > server/CGI mode. There is no mechanism (in the current code base) with which > we can simply re-set the whole environment and run a different command. Yes, and why would that be difficult to handle for a wrapper (see below)? > > > after every command fossil runs, exit() is called somewhere, which makes it > > difficult or impossible to chain commands together in the same app session. > > Why? > > The same reason attempts to adding a shell mode for fossil have failed so > far. Almost every error condition in fossil passes through fossil_fatal() or > similar, and that ends up calling exit(). So if you add a command and use any > of the db functions, and those hit any errors at all, your command will end > up exit()ing. If you mean "why does it exit() so much?" That's just the way > it was originally designed - historic momentum. For fossil's original purpose > (and its current primary uses), the current model actually works quite well, > and simplifies some of the trickier handling needed when producing HTML > output (e.g. the buffering of the body and headers, and sending them out at > the proper times). There is of course lots of interest in refactoring fossil > into a library, but the amount of effort required is huge. It could easily > take a few full-time weeks of development effort, and would probably require > the assistance of at least one person who's "exceedingly familiar" with fos sil's "more intricate bits" (e.g. how artifacts are maintained/linked/created/etc.). While i'm relatively familiar with the code in general, there are huge blocks of voodoo in there i won't touch for fear of breaking them. 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. 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. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
