On Fri, Jan 28, 2011 at 12:34 PM, Stephan Beal <[email protected]> wrote: > > > 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.
Looks fine. Were I to need json output, this would be great. I'd just make this the only output format, but.. > >> >> 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 > ;). I can't imagine a situation where specifically listing the columns to be inserted is bad or unwanted. And, for updates (which seems more likely to me), you'll have to do it anyway. In any event, both of those usecases are presumably dwarfed by the display usecase where displaying in schema order probably isn't so good as far as UX goes. (I'll grant you that for debugging, probably it is better, but developers usually < users , even if your target audience is developers.) My point in all this being that having the column list seems unnecessary. Adding in output for a small minority of users/usecases doesn't seem worth while. Even if that output will be trivially compressed anyway. Being pedantic, -B > > -- > ----- 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 > > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
