[Ovmsdev] Java and questions

[Mark Webb-Johnson]

>  I guess from my point of view its better to work on the basis that there can be only one client?

It is possible for there to be more than 1 app connected, controlling the car, but not so likely.

> Is it true to say that (network issues aside) not all 'C' messages will receive a 'c' response?

I think that every 'C' message will receive a 'c' response. Even if the message is not understood, it will come back with a failure response.

> Also, how is the car's connection handled, is it always connected to the server if it can be or only when a client connects?


The car tries to maintain a connection to the server always. There is no way for the app or server to message or call the car without that connection established.

Regards, Mark.

On 14 Mar, 2012, at 10:55 PM, Tim Putnam wrote:

> Thanks, I think I had the wrong preconceptions here. I guess from my point of view its better to work on the basis that there can be only one client?
> 
> Is it true to say that (network issues aside) not all 'C' messages will receive a 'c' response?
> 
> Also, how is the car's connection handled, is it always connected to the server if it can be or only when a client connects?
> 
> cheers, 
> Tim
> 
> On 14 Mar 2012, at 14:17, Mark Webb-Johnson wrote:
> 
>> 
>>> Ah I see so the server is just acting as a proxy and carries no state?
>> 
>> 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).
>> 
>>> 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?
>> 
>> Undefined. Most commands should be ok. Some will have an issue and the original command may get lost (overwritten by the subsequent command).
>> 
>>> 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?
>> 
>> 
>> Might break backwards-compatibility. Not sure if we could do it while maintaining compatibility (without having to extend each command).
>> 
>> 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.
>> 
>> Regards, Mark.
>> 
>> On 14 Mar, 2012, at 10:11 PM, Tim Putnam wrote:
>> 
>>> Hi Mark,
>>> 
>>> Ah I see so the server is just acting as a proxy and carries no state?
>>> 
>>> 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?
>>> 
>>> 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?
>>> 
>>> best regards,
>>> Tim
>>> 
>>> On 14 Mar 2012, at 13:45, Mark Webb-Johnson wrote:
>>> 
>>>> Tim,
>>>> 
>>>> Sounds real useful.
>>>> 
>>>>> 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?
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 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).
>>>> 
>>>> 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.
>>>> 
>>>> Regards, Mark.
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120314/cfc655fa/attachment.htm>