On Fri, Jan 28, 2011 at 9:14 PM, Brian Smith <[email protected]> wrote:
> On Fri, Jan 28, 2011 at 12:09 PM, Stephan Beal <[email protected]> > wrote: > > On Fri, Jan 28, 2011 at 9:07 PM, Joshua Paine <[email protected]> > > wrote: > >> > >> Your format is certainly lighter over the wire, but it's very much not > >> how users of JSON generally do things and expect things to work. I think > >> it's worth some bytes to be unsurprising. (And you can always gzip it > >> over the wire, which will remove most of the size difference.) > > > > i'm working on the "fat" impl now, and we'll be able to switch via > cli/cgi > > option. > > Unless you have some specific usecase for a "fat" implementation, I'd > say skip the option > and just output the format of least surprise. I can't see a good > reason to have it. > i have no special love for it. How's this: stephan@ludo:~/cvs/fossil/fossil$ ./fossil timeline -n 1 -J { "columns":[ "rid", "uuid", "mDateTime", "comment", "primPlinkCount", "plinkCount", "mtime" ], "rows":[{ "rid":10733, "uuid":"136ac24170b24db53197c00154d4424558e28eda", "mDateTime":"2011-01-28 18:49:07", "comment":"Create new branch named \"sgb-cson\" (user: stephan tags: sgb-cson)", "primPlinkCount":7342276, "plinkCount":1, "mtime":2455590.284119 }] } The order of the "columns" list is guaranteed to be query order, but the fields in the "rows" objects might be re-ordered. That way we can have both worlds if we want. > As for the key re-ordering, that's a non-issue, if I'm going to be > manipulating the data for re-insert > into the database, I'll specifically order the columns in the insert > and sort the keys myself. > Yes, but that's the kicker: this is for everyone's use case, not just yours ;). -- ----- 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
