On Thu, Oct 6, 2011 at 5:59 PM, Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote:
> Last time I checked GPB was implemented in the form of a C++ library. > Many C++ APIs can be used from C code, actually, as long as their C++-only functionality can be hidden behind an intermediary C-style API. > I think this is a no-go for Fossil. > I suspect that BSON would be easier to use for this case. > There was a HUGE (50+ message) thread on this on the JSON list a couple weeks back. As far as binary JSON goes, i like where this is going: http://ubjson.org/ But i'm still a long way from having to worry about that type of stuff right now. Once all of the text-mode features work (including checking in non-binary content) i'll try to tackle the binary problem. JSON does not have a mechanism for binary, so any solution either needs to circumvent JSON (e.g. using non-json HTTP requests) or introduce an encoding mechanism (which immediately rules out any client languages which cannot/do not have such algos). The available C implementation (from MongoDB) is licensed under Apache > License, Version 2.0 so I'm not sure about direct inclusion, but the > spec itself appears to be not so complicated so probably it can be just > implemented specifically for Fossil. > > >From what i've read about these so far, they're about the binary encoding of JSON values/trees, not the encoding of arbitrary binary data IN JSON (which is what we would need to support binary-using operations). bson also extends JSON with its own types, which is something i would much rather avoid (portability). At this moment google's protocol buffers look like a reasonable middle-ground. i do have ideas on how to solve "the too-large blob" problem, by taking the data via multiple chunks (this is how gmail sends attachments) and buffering them in a new table for a while (until the request completes or they expire and are cleaned up). But... i'm still a long way from having to tackle that problem (it is the absolutely last feature on my TODO list, and my TODO list is about as long my hair [1]). Another idea would be to reference binary data via URLs rather than transport them directly. e.g. a JSON-mode file checkout might return a URL which will directly pull that file (in raw form) from the repository, and then the client could fetch it using a binary-capable mechanism (wget for a shell client and a URLConnection in Java). Diffs and whatnot are a whole other problem altogether, because there are no clients other than fossil itself which handles fossil-format diffs. So those are also way, way down the list on the list of (potential) TODOs. [1] = with only a slight tilt of my head, i could[2] wipe my behind with it. [2] = but i don't! -- ----- 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
