The protocol you suggest is distinctly human readable ASCII. The protocol he is suggesting is a poor compromise between ASCII and binary and has the following difficulties to boot: * More difficult to parse as a human * More difficult to parse as a machine * More susceptable to line noise * Much more bandwidth required (don't use it over cellular!) There is a difference between stream encoding and discrete encoding, and your particular application should suggest one approach over the other. His is more stream based, yours is discrete. I'd be asking him: "Why are you trying to marry, and poorly so, binary stream communications with ascii record communications? What is the advantage? Despite my obvious lack of computer science, I need you to explain this in a way that I can understand and explain it to others. If you can't teach it, then you obviously don't understand it well enough to safely implement it, and we prefer you use a method we can prove is reliable." Of course, you'll have to say that in a more tactful manner. I suspect he made a choice, and wants to stick with it, though there's no good reason to do so. Sounds like a bad worker though - I bet you've had to hold his nose to the grindstone more often than you'd like. In terms of time/value, it is easier to change the output than the input. However, if he is a consultant or seperate entity then it may be cheaper/faster for you to change the input. Lastly, sounds like a turf war. "Best Practices" are all well and good, but who is the real customer, and how is this going to affect them? Unless otherwise specified, fix it in a way that meets requirements, and make a mental note about how this particular person has to be dealt with in the future. It's annoying, but it smacks of "not invented here" and all the extra email, discussions, and lateness aren't going to help your position even though you may be able to show that it's not your fault. If you had the power to fix it silently, you may still be considered part of the problem. Plus it's fun - "Yeah, he mis-implemented the protocol that I emailed everyone at the beginning of the project, but I coded the parsing scheme to accept both his bastard protocol and the correct protocol. Hopefully he'll fall in line, but if not at least we can move forward." Make sure to CC him on any such communications. Doesn't work in environments where the spec is document controlled and signed off, but if that were the case then you wouldn't be having this problem... -Adam On 9/30/07, Peter Todd wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Practically all commonly used protocols on the internet, at least the > ones that use TCP as a transport, are line oriented, text based and > human readable and writable. Is there an actual RFC (or similar > standards document) describing this practice as a "best practice"? > > I ask because at a job I have I wrote a little server app that has a > protocol along the lines of this: > > beat X Y V\n > beat X Y V\n > beat X Y V\n > > There X, Y are indexes to an array and V is the value to put in the > array. The application needs essentially no extra functionality and is > without a doubt a prototype that will be thrown out before the next > revision. The whole reason why there even is the protocol is due to a > temporary architectural hack. I did my server part of the project weeks > ago and it was quite nice being able to simply telnet and type the > commands manually. > > The other engineer on the project, who is working on the client, wants > me to change it to essentially this: > > SetBeatXStepYValueVSetBeatXStepYValueVSetBeatXStepYValueVSetBeatXStepYValueVSetBeatXStepYValueVSetBeatXStepYValueVSetBeatXStepYValueV > > There really are supposed to be no spaces, newlines, or nulls, between > the command packets. That's exactly what he wrote his app to produce. > The last time we met to integrate the two halves, he crypticly said > there was a deep reason for the above that I, without 4 years of > computer science, was never going to understand. If he's thinking job > security, I think he is wrong, because the whole app would take about a > weekend to write, and his client part of it is already 4 weeks late. I > figure I could get it done in a week, including learning Java on mobile > devices... > > Anyway, if I'm not going to convince him, at least I might convince our > bosses why I think he is completely insane. RFC's just might help build > my case. I've got a nice list of every internet protocol I could find > using this design, but a meta-document would be even nicer. > > - -- > http://petertodd.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFG/8In3bMhDbI9xWQRArbnAJ971WGb+TXemCbvgFtT0oM6gt7QtACfSd2H > mqOVw9Kjjoa+hNjGDoy8yls= > =tdT/ > -----END PGP SIGNATURE----- > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Moving in southeast Michigan? Buy my house: http://ubasics.com/house/ Interested in electronics? Check out the projects at http://ubasics.com Building your own house? Check out http://ubasics.com/home/ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist