Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Official RIVA thread
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
AFAIK, they should be the usual quoted comma string. So quoted values, separated by commas. If a parameter has no spaces I think it'll let you get away without the quotes, but it's typically easier to just quote them all and make it consistent.
I'm not sure I understand. According to the XML Gateway spec, each parameter appears in an enclosing XML element, and the example does not show commas or quotes anywhere as far as I can remember. Can you give me an example of what XML I should send if the first parameter is FOO, the second parameter is blank, and the third parameter is BAR?
Oh, sorry. I was in another world there. You seem to be doing the right thing. What exception are you getting if you pass in an empty parameter? Note that you can also save space by doing empty elements like this:

<CQCGW:MacroParm/>

instead of doing a separate end element. It might make a difference perhaps on smaller wireless devices I guess.
More XML Gateway questions.

*** Serial Numbers

The command to retrieve event information has a serial number, so CQC can return information only about events which have changed. Does the serial number persist across multiple connection sessions? It looks like it does, but I wanted to make sure, so that after reconnection I can still send the most recent serial number I have, rather than having to send a 0 again and reload the data.

I was also noticing last night that the serial number seemed to change without any actual difference in the events. I saw two successive serial numbers where the event data was character-for-character identical. Any idea why that would happen?

*** Disconnects

Right now, my XML Gateway client stays connected until it gets the disconnect message from the server after a minute of the user not needing any more information, at which point the client disconnects (since the server does so anyway). It sounds, though, like this might cause an error message in the server log, meaning that maybe you don't expect clients to behave that way. Am I supposed to proactively disconnect after a certain period of time? To disconnect, do I just close the connection, or am I supposed to send some sort of message?

*** Macro Parameters

When I send a blank parameter, either via <CQCGW:MacroParm></CQCGW:MacroParm> or via <CQCGW:MacroParm />, I get an exception:

<CQCGW:ExceptionReply CQCGW:ErrClass="EClass_BadParms" CQCGW:ErrSev="ESev_Failed" CQCGW:File="CIDXML_SimpleTree.cpp" CQCGW:Line="957" CQCGWTonguerocess="CQCGWSrv" CQCGW:Thread="CQCGWSrvWorkerThread0">
Got a child index of 0 but only 0 exist in this CQCGW:MacroParm element
</CQCGW:ExceptionReply>

When I send a parameter consisting of a single space character, it does not give me that exception. So should I always convert blank parameters into single spaces?

The server behaves somewhat sullenly when I try to send non-numeric data for a numeric parameter. I have a test macro that takes a single integer parameter. When I send "1asdf" as the parameter value, I get back an UnknownExceptionReply message, and then the server disconnects. Swift and exacting justice! Since there is no way for me to know that I need to validate the parameter as an integer, it's difficult for my program to avoid this fate.

*** Field Values

I noticed an amusing quirk. I wrote "034" to an integer field, and when I read the value back, it was 28. I eventually realized that you must be using scanf or something like that which accepts octal numbers with a leading 0. I didn't check, but would that also work with 0x for hex? Is this documented behavior? Does it apply to macro parameters as well as field values?

*** Global Actions

I was talking to Commander Vimes about global actions. He thinks it would be useful for my client to allow him to execute them. But am I right that there's no list of available global actions the same way there is for macros? Are there any guidelines for correct syntax of the global action string?
Quote:*** Serial Numbers

They won't persist, so if you lose the connection you have to get them again. They will go back to one. Any time you lose the connection you should reset yours to zero, to insure that you don't get out of sync.

Quote:*** Disconnects

Yeh, it assumes that you are either going to poll fields periodically, or do some sort of dummy operation periodically to keep it open. If you really want to close it, we need to add a formal shutdown request (assuming there's not one already, I'll have to check) so that you can indicate explicitly that you are closing the connection.

Quote:*** Macro Parameters

Oh, OK. I get it. That's my bad. I'm just blindly looking for the 0th child element of the macro parameter element, which would normally be a text element. But if the element is empty, there won't be on. So I need to fix that for the next drop.

Quote:*** Field Values

It doesn't use scanf, but our own versions of that stuff implements similar sort of rules that are consistent throughout CQC. 0x will work as well for hex values.


Quote:*** Global Actions

It's one of the generic commands done via the CQCGW:Query element. You pass in CQCGW:QueryGlobActs as the query value. It looks like I failed to get that (and the stuff defining the returned info for that query) into the document. I'll update that, but in the meantime, this is what comes back, similar to Macros:

Code:
//
        //  This block defines the response to the CQCGW:QueryGlobActs query.
        //  It returns the list of currently defined global actions. This is a
        //  hierarchical structure. So it starts with a scope, which can in turn
        //  hold zero or more other scopes or global actions.
        //
        L"<!ELEMENT  CQCGW:GActName EMPTY>\n"
        L"<!ATTLIST  CQCGW:GActName\n"
        L"           CQCGW:Name CDATA #REQUIRED>\n"
        L"<!ELEMENT  CQCGW:GActScope (CQCGW:GActScope*, CQCGW:GActName*)>\n"
        L"<!ATTLIST  CQCGW:GActScope\n"
        L"           CQCGW:Name CDATA #REQUIRED>\n\n"
Thanks. So when the device is going to go to sleep, and I need to disconnect, I will simply close the connection, correct?

And regarding the unknown exception and disconnect when I send non-numeric data in a numeric macro parameter, can that also be cleaned up?
brianmount Wrote:Thanks. So when the device is going to go to sleep, and I need to disconnect, I will simply close the connection, correct?
I'm not sure you really want to force a disconnect every time the screen goes dark, as people are likely to wake it back before the wireless antenna actually shuts down...
brianmount Wrote:Thanks. So when the device is going to go to sleep, and I need to disconnect, I will simply close the connection, correct?

We should probably do two things. One is to provide a formal disconnect message you can send to say you are officially closing the connection, so the server won't think it's an error.

The other is to perhaps consider the same thing we are considering for the RIVA world, which is the ability for the server to keep connections alive permanently and the RIVA client just connect to them. A similar sort of thing could be done here as well maybe.

Quote:And regarding the unknown exception and disconnect when I send non-numeric data in a numeric macro parameter, can that also be cleaned up?

OK, I'll check that. I assume it's more general and just to be sure to recover from any failure to convert parameters to their target types.
The nice thing about the gateway protocol is that it's mostly stateless. In the iPhone environment, an app can keep running in the background forever, and the phone can go to sleep any time. This is difficult to deal with in the Riva client, but in the XML Gateway client it's not a problem. My plan had been to let the server disconnect me whenever it wanted to, disconnect myself whenever going into the background or going to sleep, and reconnect as needed. The user experience should be unaffected save for a brief pause to reconnect whenever new data is required. Unlike Riva, I don't really need a persistent connection for any reason. Further, we can't keep a connection alive forever when we go to sleep, and even when the phone is alive we wouldn't want to keep it alive without a good reason, because the app might be dormant in the background, not really needing the connection for anything. So I'd say the current state of the protocol is fine. The only question is whether an explicit disconnect message needs to be added so that the server doesn't think there's a problem. Or alternatively, we could just change the server so it doesn't think it's a problem for a client to disconnect without warning.
I'll definitely add a formal disconnect. It's important for determing issues after the fact when looking at the logs, to know that the connection really is being dropped unintentionally.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39