Hi, >> Ideally (and longer-term), i think we could/should implement JSON >> interfaces into/out of fossil, so that we could write AJAX apps on >> top of fossil. With that in place, multiple WUIs could be created >> using one's own favourite JavaScript library (*cough*jquery*cough*). >> i've been looking at C libs lately for adding some JSON output >> support to fossil (e.g. timeline/commits data), but the open source >> JSON-generation C libs i've looked at "just don't do it for me," and >> i haven't yet settled on one (i don't want to implement one if i can >> avoid it, though it might be useful to implement a custom one on top >> of the fossil blob data type, to take advantage of the memory >> management). > > Personally I'd be more inclined to use pure XML over JSON to give > greater flexibility, as much as I detest XML as a format, it seems > every programming language out there I've ever dealt with has some > sort of XML library. Hey, even Applescript has ways of parsing it. Or both.
I haven't been following this conversation closely, but the nature of data managed by Fossil makes it highly conducive to a REST API rather than an RPC API. The information uploaded to Fossil (send in through the API) is typically light on metadata (especially structured metadata), and the cases I can think of offhand can be handled by POST and content-type=application/x-www-form-urlencoded or content-type=multipart/form-data. In the absence of complex/structured metadata there is no need for JSON or XML. When retrieving/downloading through the API more metadata is available, and it would be easy to support multiple representations of the same resource by using a .xml, .json or .html extension. Regards, Twylite _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
