Hi, all! Management Summary: if you are _at all_ interested in seeing a JSON REST-style interface added to fossil, please continue reading. If not, don't bother!
Since you've read this far, we'll go ahead and continue... Earlier this week i was awarded the great pleasure of sitting down with DRH himself for dinner in downtown Munich, Germany on what was coincidentally the absolute nicest day we've had this whole summer. At one point Richard asked me, "what does Fossil need?" To which i answered: 1) A split between library and app. i.e. libfossil vs. the fossil server/cgi/shell app(s) 2) A JSON interface. We very quickly agreed that (1) would require a herculean effort (trust us on this!), and discarded it. Richard agreed, however, that a REST-style[1] interface could be a big benefit. The topic of a JSON interface has come up on the mailing list before but has so far received (IMO) a luke-warm response at best. Nonetheless, inspired by Richard's interest in the topic, i'm gonna try once again to drum up some support... Let me start by naming just a very few of the things we could do with a JSON interface: - Write completely custom UIs in any language supporting JSON (that's every programming language in modern use). 3rd-party UIs could be implemented in _client-side_ HTML/JavaScript/CSS. You've always wanted a slimmed-down Fossil UI for your mobile phone, right? - Write special-purpose mini-applications, e.g. a desktop notification (or in-web-page) applet/widget which polls for new commits or tickets, and maybe sends emails when something arrives. This could be used to partially work around Fossil's lack of post-commit hooks (with a time delay, and pre-commit hooks could not be done this way). - We could create repo-consolidation sites which contain an overview of any number of 3rd-party repos (e.g. the timeline from each could be presented). - We could consolidate the wikis of multiple repos into a single site using AJAX, JSON, and a client-side (e.g. JavaScript) implementation of the wiki parser. (i've got one for Google Code format[3] which "shouldn't be" too hard to adapt to Fossil (which has a simpler dialect).) - By serving wiki pages via JSON, and rendering them on the client, fossil repos could potentially use any wiki format for which they have a client-side parser. (i KNOW some of you prefer Markdown/Markup/Marktwain.) That's just the things which immediately come to mind. That all sounds great, and we're not there yet, but here's what we do have... Some months ago i created a fossil fork[2] which includes some proof-of-concept for adding JSON support to Fossil. That fork[2] is merged in against the current (as of yesterday or the day before) trunk, but it only supports JSON in certain CLI-mode commands (timeline+tickets), as opposed to via HTTP. Adding a "pure JSON" HTTP interface will require some refactoring, but not nearly as much as splitting Fossil in a library/app fashion. We have to do things like make sure that only JSON (no HTML) is output, make sure we handle the exit()-on-error cases differently (we need to output a JSON response there) and generally tweak Fossil's "native" internal workflow in some places. For example, for a command which incrementally outputs HTML, we can't simply stuff JSON output in the middle of it because the HTML effectively corrupts the JSON response. That's just to say that there's going to have to be some internal refactoring. Not heart surgery, mind you, but we might have to swap around a couple minor organs ;). To try to wrap my mind around what would (will!) be needed to add a JSON-based API, and what benefits it could provide, i have started writing a document which superficially looks like a draft specification or RFC but is in reality just a scratch-pad for ideas: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?pli=1 i am VERY interested in YOUR ideas and feedback, and getting other collaborators on board, even if they're only interested in helping shape the JSON interface but not in writing C code. The above doc is world-readable, but i would be happy to give write access to anyone interested in helping to flesh it out (just send me your Google Mail address and i'll add you to the list). i recently implemented a pure-JSON CGI wiki system[4] which uses sqlite3 for storage, inspired completely by Fossil, so i'm currently "in JSON/C/CGI mode", and don't mind writing all the code myself. But i would very much appreciate the list's input on what the JSON interfaces should (or should not) look like. (And if someone else actually does want to help hack, then the more the merrier.) While i have turned in my Fossil copyright waiver and once again have commit access to fossil, i'd prefer to keep these changes in a separate fork[2] for the time being to avoid muddling up the main repo with a couple hundred kb of stuff (the underlying JSON lib and JSON/sqlite3 binding bits) until it is clear that this approach is worth continuing (and works on Windows - i've never tested the JSON library on non-Unix, but it's all plain C89 code so it "should be portable"). Until such a time, i will merge in (and conflict-resolve) the official trunk fairly regularly so that an eventual move to a branch in the main repo should be painless. i am of course happy to add contributors to that fork - send me your preferred login name and i'll get you set up ASAP. If a REST-style JSON interface to Fossil would be useful to you, then help us create one which would be useful for you. The more varied the opinions (and we've all got them!), the better the API is likely to turn out. If you remain silent, the one(s) writing the code will end up making all the decisions (and we all know that passive onlookers always have better ideas about how to go about something than the people who are doing the real work ;). Happy Hacking and Good Night! [1] REST: http://en.wikipedia.org/wiki/Representational_state_transfer [2] JSON fossil fork: http://fossil.wanderinghorse.net/repos/fossil-sgb/ [3] Google Code wiki format parser: http://code.google.com/p/wikiwym/ [4] JSON-based wiki back-end: http://whiki.wanderinghorse.net/ -- ----- 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
