On Thu, Sep 8, 2011 at 10:11 PM, Martin S. Weber <[email protected]>wrote:
> On 09/08/11 16:01, Stephan Beal wrote: > >> 1) A split between library and app. i.e. libfossil vs. the fossil >> server/cgi/shell app(s) >> > > I couldn't agree more. One of my goals (luckily no milestone I'll ever be > evaluated against) is to do that. > i can promise you that "herculean effort" was not a hyperbole! That said, i would be happy to assist you in this, and i think it can be done incrementally, taking a long time to do but having no outwardly effect on the apps. > 2) A JSON interface. >> > > I agree with the REST interface, choosing JSON seems natural, then. But > then again, you only need the JSON for the replies, not the requests > themselves, as the URL will contain the query (update, drop, ...) already. > In case you have data to accompany the request, I'm not sure that JSON is > the right choice (in contrast to multipart/forms), but I don't have a strong > opinion on that one. > See the draft doc - SOME requests (commit) would benefit from POST, but yes, the majority can get by with GET. i recommend JSON mainly for portability. It can be generated (with some limitations) even from shell scripts and posted via wget or curl. Form-encoding is more expensive and (with JSON) unnecessary. That said, i have code in place (in another tree, but it could be ported) for translating form-encoded data into a JSON object so that the application can treat both forms identically. i.e. with that in place form encoding can also be used and the app doesn't need to change except for the initial parsing code (which type to parse depends on the CONTENT_TYPE header). > That being said, what about the CLI? If you're using client-side UI, then > the CLI should do that, too, shouldn't it? May I point to the wonderful > jansson C library (even though it's maybe too late already?), an easy to > use, lightweight, BSD licensed json library while we're at it. > jansson is very nice (i only discovered it last week), and the library i'm using is actually (and 100% coincidentally) _very_ similar to jansson. (i emailed jansson's author last week about that, actually, and we discussed a few implementation differences.) The current code (called cson) is Public Domain, so there's no licensing constraint. See: http://whiki.wanderinghorse.net/wikis/cson/ My fossil fork contains a trimmed-down copy of that project's amalgamation build. Or is the CLI still going to be a "special case" ? > i would also like for the CLI to be able to spit out JSON (and possibly even read "requests" via stdin, which can internally be treated as POSTed JSON), but that's a secondary goal for me. The JSON-emitting code is actually very minimal - it uses the existing SQL queries and blindly (with no interpretation other than figuring out each field's data type) translates the results to JSON. Because of that, it's especially easy to add to CLI commands (i have it added to tickets and timeline in my copy). Adding an HTTP interface will require more internal refactoring and internal infrastructure, as opposed to only function-local changes like the CLI JSON integration typically requires. i recently had to implement all of this for another app (also a CGI in C), so it's clear to me what infrastructure we generically need, it's now just a matter of doing it. The infrastructure is largely independent of the public JSON interface, so i can continue to implement that in peace while we all bat around the important parts - the public interfaces. Here's an example from the CLI (pedantic note: it doesn't conform to what the doc i posted suggests because i'm not yet far enough along, at the fossil/json infrastructure level, to do that. That doc represents the goal/ideal, not the current state.): stephan@tiny:~/cvs/fossil/fossil-sgb$ ./fossil time -n 3 -j {"columns":["rid", "uuid", "mDateTime", "comment", "primPlinkCount", "plinkCount", "mtime"], "rows":[{"rid":13466, "uuid":"9c74371928779b08704116581cd79476e3e1eb0f", "mDateTime":"2011-09-06 21:27:38", "comment":"timeline json: now only add LIMIT clause if n!=0. Added a FIXME regarding showfilesFlag support. (user: stephan tags: sgb-cson)", "primPlinkCount":0, "plinkCount":1, "mtime":2455811.394196}, ... (i _really_ hope your mail client wrapped that!) Anyways, thumbs up! > :-D Thank you for your feedback - keep it coming! -- ----- 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
