EZServ XML API 2.0 proposal

[Anonymous]

#40070

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?

[Anonymous]

#42309

No comments at all (either for or against)?

[Anonymous]

#42310

I agree, for the most part. In an ideal world there would be a JSON API over HTTP (obviously using one of the XSRF countermeasures like cookie doubling in header) so that you could do browser mashups with the thing, but even without that this would be MUCH more useful over HTTP, even if it’s “raw” XML over HTTP and not even one of the standards like XMLRPC or SOAP. (Those two are both complicated enough that I wouldn’t bother, but a simple request -> XML response would be fine.)

In fact what I’d REALLY like to see is an AtomPub API (Atom over HTTP via REST): http://www.atomenabled.org/ The idea would be that each configured device would be an in a . Even if it only existed for read-only data (i.e. an Atom feed instead of an AtomPub service), this would be super-useful.

The main problem with the current implementation is that it is exceedingly unfriendly to mobile applications (which is what I am interested in): you must manually keep a persistent socket open while considering transient/poor network connections and obnoxious carrier topologies that favor HTTP/HTTPS.

[Anonymous]

#42311

Specifically regarding your comment about omitting the tag — yes, it’s really not an option to leave that unfixed. The current implementation requires that the code handling the stream I/O also be aware of XML, which is extremely obnoxious.

[Anonymous]

#42312

Maintaining a very long term socket connection to the EZServe also has its complications. Now you have to worry about maintaining that connection after reboots on either end. I’ve suggested that the EZServe be configurable with an IP address/port such that everytime it has activity it would make a connection to that address, send the XML message in the EZServe format, then drop the connection. That way the job of providing a robust server to handle such messages would shift off of the EZServe.

[Anonymous]

#42313

That is a very interesting concept, though I’d also like to see a hostname as an option. One could set up a very simple Google App Engine app to handle such state-change pings (which would be free), but would require a hostname due to DNS load-balancing.

[Anonymous]

#42314

I actually meant hostname, not a numerical IP address. Devices I’ve used which require a numerical IP address are a pain in the neck.

[Author]

Posts