[EMAIL PROTECTED] wrote:
I like your concept and agree with your design choices, so much in fact
that I independently implemented a very similar system. In my case I
packaged the responses in XML,
Difficult isn't it, XML or no XML :-) I had also considered XML, if
nothing else it is the 'in thing'. But the other side of the coin is
that if your XML replies do not comply to a recognised dictionary, the
only advantage is that ready made parsers are available.
Apart from the horrendous overhead of XML, it is not necessarily easier
to incorporate a ready made but complex library than it is to implement
a very simple parser from scratch. But when I factored in the
possibilities of connecting from environments like PLC's and scripting
environments where an XML parser is not necessarily available it became
a no brainer. My underlying philosophy was KISS, and perhaps a better
name for the techfell protocol (which is historic and pre dates
uSQLite) would be SPP, Simplest Possible Protocol.
parser for flexibility. Even with the added overhead it is fast enough
to get comments from users. Don't be discouraged.
You mean it was allready available?
I wrote it. I used XML in the end because it can map a complex data
structure into a single document. In that case what you lose on the
swings (XML) you gain on the roundabouts (TCP/IP), particularly if you
use HTTP for transport. At the client end it requires a rather complex
parser, a mindless overhead for an embedded system but no sweat for a
modern PC. I use a client parser based around a transformed DTD driving
our old friend "expat".
This type of RPC in my experience leaves ODBC floundering in the weeds.
A general comment. KISS, or Occam's Razor for us diplomats, is sadly
neglected in today's software. Keep the faith.
