On Wed, Feb 13, 2013 at 6:28 PM, Stephan Beal <[email protected]> wrote:
> That's correct, for two reasons: > > a) The JSON API is centered on remote use, and remote use does not > (typically) have a checked-out copy immediately available to it. None of > the existing JSON commands know how to deal with a local check-out. > To elaborate on why the json command is available from the CLI (despite it being "remote-centric")... Primarily because it's 10x easier to develop and test that way. There are only a few relatively minor internal differences in the CLI-vs-CGI handling, so the json code is 98% identical for the two (CLI-vs-GET parameter handling is different). First the code is written to run from the CLI, and then tweaked (if needed) for over-HTTP purposes. Secondarily, though not a primary design goal, is that the CLI version can be used with a wrapper to emulate remote access via a local fossil binary. Why would one want to do that? "Because we can" ;). An example/proof-of-concept of this is in the source tree: ajax/js/fossil-ajaj.js (search for "rhinoLocalBinarySendImpl"), which in turn is used by ajax/i-test/rhino-test.js. That demonstrates using multiple connection options - HTTP and local binary - via the same abstraction API. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
