brianmount Wrote:Dean, a couple questions about the protocol version. First, I was trying to connect to Sam Vimes' server using protocol version 4, but he hadn't upgraded yet. I thought that in past I got protocol version rejects when I tried this. This time it seemed like my login request was accepted, but then the server dropped the connection on me. Do you know what the expected behavior when the client uses an unsupported protocol version?
I would have thunk that you would have gotten a rejection. I'll look into that.
Quote:Second, I was wondering if there was some way to negotiate the protocol version. From the client's point of view, it would be great to use version 4 if available, or version 3 if not (and so on). I guess I could repeatedly attempt a connection with decreasing protocol version numbers until something worked. But might there be a way for the client to send a protocol version number, and the server to counter with the highest version it can support? The client can either disconnect and give up if the supported version is not high enough, or continue, using the server's version. Just a thought -- I don't have a fully-worked-out suggestion.
I guess that the rejection could include the highest version supported and you could try again using that if you want to try to support multiple versions.
SamVimes2 Wrote:A question about the RIVACmd: is it intended that the command is not available in a template OnLoad or OnPreload?
I think the suggested use case (at least for a web widget kludge) is that a single template can be made to work with both RIVA and the regular IV by having a web widget (that will display in the regular IV and get ignored by RIVA) and an OnPreload/OnLoad action of form RIVACmd[WebWidget, URL, x1/y1,x2/y2] (that will get ignored on the regular IV and processed by a RIVA client).
Thoughts?
I hadn't thought of it in those terms, but that would effectively be the case. The RIVA system won't see the web widget since it never gets loaded in that case, and the regular IV doesn't process the RIVACmd commands.
I found the problem that was causing the lost connections. I was mistakenly sending the old-format login request in cases where I didn't have any environment variables to send. It looks like I need to send the new format even if there are none.
FYI, the reason I found the problem is that the server log said "Got opcode 105 but expected 102." In fact, you received 102 but were expecting 105. So I think your error message has the two numbers reversed.
I'll fix the error message also, thanks for catching that. If you say you are V3 or beyond I think you do have to send the new login, even if you don't have any variables to send.
Dean Roddey Wrote:I hadn't thought of it in those terms, but that would effectively be the case. The RIVA system won't see the web widget since it never gets loaded in that case, and the regular IV doesn't process the RIVACmd commands.
Does this mean we'll be able to use the commands in OnLoad or OnPreload at some point? we've got this pretty close to ready.
It might be tricky using them in the OnLoad or OnPreload, but I guess it's your responsibility to deal with the issues depending on what you allow users to send you with this command, so I have no problem enabling it. I guess on the RIVA end, since it doesn't deal with widgets themselves, there's no danger of trying to access things that aren't set up yet.
So, if I was to make a new V5 of the protocol, to get support for the multi-line segment drawing command that is required for supporting graphs, is there anything else that we can slip in while I'm creating a new version? It would need to be stuff that isn't very complex since we are too close to 4.2 for that. But if there's anything else that would be useful and not too heavy I could do that while I'm making changes.
Dean Roddey Wrote:It would need to be stuff that isn't very complex since we are too close to 4.2 for that.
One easy part for protocol 5 could be to accept the client's resolution during the login, without doing anything with it.
Then let say in 4.5 you could pre-scale everything server side, so that people can use their regular templates on devices of any resolution (matching the orientation)... No provided resolution would mean no pre-scaling...
