I’ve learned a lot while trying to work with the existing EZServ XML API and think I’ve got some good ideas for the 2.0 release. Here’s a summary:

Background:

The existing API output puts out a toplevel object and outputs a
before every message. All of this is parseable with a custom parser, but seems to break EVERY standard XML parser as both of those things violate the XML standard. XML only allows one root object per document. The only workaround I’ve found is to pre-parse the input to break it into chunks and set up a new XML parser for each piece – not great for efficiency.

There are two types of XML parsers out there, the first reads in a whole document at a time and then returns it and the other reacts to each element as it comes in – both however require a valid XML document with just one root element per document.

Proposal:

The EZServ should output just one long document every time you connect on port 8002. The layout of this document would be like (indentation for the example only, doesn’t matter for the real device):

0x2
…
0x2
…
0X2 …

Now the trick is that closing often never really happens because if the programmer is using the type of XML parser which reacts to each element as it comes in they just keep listening on the socket forever and reacting the the elements as they come in. Also notice that the at the top happens exactly once per connection on the socket right at the time of the EZServ accepting the connection on the socket. Now if the client programmer happens to have an application where the “parse entire document” type of XML parser makes sense (maybe for short duration connections), there should be a new command the computer can send the EZServ:

and the response is a dumb echo of exactly:

so if the programmer NEEDS the XML document to be terminated it is very easy to make it happen. Presumably the computer would send the , receive the , parse the XML document for the whole session, then end the socket connection. Feel free to call it something other than endSession, I don’t care what it’s called as long as the function is there.

Also note that I’ve changed the response message so that InsStdMsg is an attribute of the Response object rather than a Text Node which is at the same level of the Parameter nodes. This is just a better XML style – the parser doesn’t have to hardcode the assumption of the position of the text node which eliminates some awkwardness in parsing the resulting XML structure output by the parser. I’d recommend also using this style for the commands sent to the EZServ:

instead of GetLatLong for example is better form, but since generating the XML for either is no big deal so whatever is easier for you to parse on the EZServ is OK with me.

I believe the changes above would be easy to implement on the EZServ side and would greatly simplify writing client code – every off the shelf XML parser out there would be able to correctly parse the output of the EZServ without messy preprocessing.

What do others on the forum think?