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 (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. > Actually, I was thinking that http/json was a more modern and universal API > for doing a fossil lib than an API based on a long list of C functions and > structs. > In a way it is, but at the lowest level it's of course all C bits. But once we have a usable JSON API in place, the effect will basically be a "library used over the net" instead of one you link to directly. Not that i'm discounting the idea - it's fundamentally a good one (and could even allow json-over-ssh/rsh/whatever, as Alaric mentioned). But it won't work out of the box on the current code base. It is, however, something i will certainly keep in mind as the library gradually mutates in a direction where that would be feasible. > 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 fossil'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. -- ----- 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
