<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Ah I see so the server is just acting as a proxy and carries no state?</div></div></blockquote><div><br></div><div>Yes. We try to make the server do as little as possible. It is just a store-and-forward relay (for messages) and forward-only relay (for commands and responses).</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error?</div></div></blockquote><div><br></div><div>Undefined. Most commands should be ok. Some will have an issue and the original command may get lost (overwritten by the subsequent command).</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request?</div></div></blockquote></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Might break backwards-compatibility. Not sure if we could do it while maintaining compatibility (without having to extend each command).</div></div></div><div><br></div><div>We could do it on something like the client version. At the moment it is "C 99,p1,p2,p3,etc". We could make v1.3.0 or later handle "C 99-key,p1,p2,p3,etc" and respond with "c 99-key,r1,r2,r3,etc". The problem is that if you send that format to a v1.2.0 client it will fail.</div><div><br></div>Regards, Mark.<div><br><div><div>On 14 Mar, 2012, at 10:11 PM, Tim Putnam wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Mark,<div><br></div><div>Ah I see so the server is just acting as a proxy and carries no state?</div><div><br></div><div>When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error?</div><div><br></div><div>What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request?</div><div><br></div><div>best regards,</div><div>Tim</div><div><br></div><div><div><div>On 14 Mar 2012, at 13:45, Mark Webb-Johnson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Tim,<br><br>Sounds real useful.<br><br><blockquote type="cite">Please may I also ask a question - what is the model for synchronicity of the messages? On the android app, if I hammer a button, I appear to be able to send more than one command before a response comes from the server. Is this correct? The protocol appears to not allow you to correlate the response from a command to the request (unless I've missed it), so doesn't appear to be asynchronous, although data messages come from the server asynchronously. Is the intended interaction with the server that there is only ever one active command in action?<br></blockquote><br><br>The command part of the protocol is pretty minimal at the moment. It was added one quite late, and does just the bare minimum of what is needed.<br><br>The server doesn't care about the command massages. Any command from the apps it sends to the car (if connected). Any response from the car it sends to _all_ connected apps. The only exception to this is that it does respond to one command itself (the one for GPRS utilization data).<br><br>The main limitation is the car module. That can only handle one command at a time, and while it is processing it you shouldn't send any more commands. Most commands will be processed within the same cycle, but some take a second or two.<br><br>Regards, Mark.<br></span></blockquote></div><br></div></div></blockquote></div><br></div></body></html>