On Sun, May 15, 2005 at 03:19:27PM +0100, Joel Crisp wrote: > Hi > > Just a small comment; maybe a format using the numeric prefix familiar to > us all from RFCs like > > 200 OK UNKNOWN test/foo > 201 foo.h > 201 foo.c
There's no guarantee that automate commands will have textual output. (For instance, they might cat a binary file out of the database.) How about, nice simple length prefixing? Each output consists of a decimal number, then a colon, then that many bytes of output. Standard flaw in this approach is that if there's a lot of data, you have to generate it all in memory before you can write any of it out, because you need to wait and figure out the length. Standard solution is to allow chunking. Each output consists of a done/not-done flag, then a decimal number (maybe with a comma to separate them or something), then a colon, then that many bytes of output. This is trivial to process (even easier than scanning for ### thingamajigs), and avoids all the quoting headaches such approaches cause. If you want to be really fancy, you could add some sort of tag to each output packet, like "this is (part of) the output for command number 7". Dunno how useful that would be. I also haven't looked at how this parses the strings that are written to stdin to get a command out, but I suspect that similar tricks would be a good idea. Maybe make the format the constant "l", then a bunch of <decimal length><constant ":"><that many characters> argument strings, then the constant "e" to mark the end of the list. Semi-arbitrary, but happens to be the same as bencoding :-). Definitely better than trying to do real command line parsing, with quotes and argument splitting and goodness knows what... -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
