On Wed, Jan 12, 2011 at 11:57 AM, Stephan Beal <[email protected]>wrote:
> On Wed, Jan 12, 2011 at 8:54 AM, David Bovill <[email protected]> wrote: > >> On 11 January 2011 21:45, Joerg Sonnenberger <[email protected]>wrote: >> >>> There is libmj, which can be found in netpgp. It's less than 20KB in >>> size for both parser and writer. >>> >> ... >> > i downloaded libmj last night, but there's maybe 3 lines of docs in the > whole code and no examples of how to use it. The man page describes what it > is for, but doesn't demonstrate its usage. When i started looking through it > to figure out how it worked (its design seems reasonable enough, and the > code well-structured) i found an apparent memory leak in the tree destructor > function, so my enthusiasm was dampened a bit. i'm waiting to hear back from > the author, and if he's responsive i'll take a closer look at libmj. > i heard back from the libmj author about the leak, and got a gracious offer for help in getting started with the library, but by that time i had already started hacking my own: http://fossil.wanderinghorse.net/repos/cson/ It's only a couple days (well, nights) old, but the overall API is more or less how i want it. The input parser bits are "90% finished but not yet tested", so there's a small bit of work to do there. The output parts seem to work as designed and be leak free (when used properly, that is). It can stream its output to any destination via a callback, e.g. to one of the fossil "clob" objects (which are used throughout the fossil code as string/artifact/zip file buffers). Historical note: to-json-string code uses the UTF traversal code from sqlite3, which i stole a few years ago for use in another project and then transplanted (almost full circule) here. Without those bits i wouldn't have had a chance in hell of supporting anything but ascii without introducing a dep on some 3rd-party lib. The underlying input parser (written by someone else) supposedly handles UTF8/16, but stores (i think) internally in utf8. If there is an outcry of support for exporting certain fossil data as JSON, i would ask the group to propose JSON schemas for the relevant areas. (i'm thinking: timeline, maybe wiki pages... what else?). If we can agree on something, and with Richard's blessing, i'll finally get around to sending off the fossil code license disclaimer so i can get commit access back, and i'll start working on it. :-? -- ----- 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
