[EMAIL PROTECTED] wrote:
-------- Original Message --------
Subject: Re: [sqlite] uSQLiteServer Source code available
From: John Stanton <[EMAIL PROTECTED]>
Date: Mon, November 14, 2005 9:47 pm
To: sqlite-users@sqlite.org
[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".
I wish I had seen this before I started. Of course parsing the XML would
be a very heavy task if you have to roll your on client, so it would not
have fullt satisfied my criteria. Also, as I generally don't use HTTP (I
deal with industrial systems which tend to be closed to the internet)
perhaps I would have more to lose than gain. So perhaps it is a good
thing I did not see it, or I might have taken th 'lazy way out'.
But what I have been thinking is what about merging the technology, you
send a #PPRAGMA XML and wham, you get an XML reply.
I know little about the details of implementing XML, and nothing about
using it over http, so I don't know how feasible this would actually
be. It would be possible to have the #PPRAGMA XML command as the first
string sent to the server.....but how do you send commands? If they can
just be sent as query string as on uSQLite then it would be easy. When
switching to XML mode you would supply a different callback function to
the sqlite3_exec command and that would generate XML replies. Presumably
it would also be necessary to modify the :Err and :OK replies as well,
but that is no big deal.
That would make it possible to put the XML capability in a conditional
compile (allthougth I expect the **generation** does not take up that
much space anyway).
A general comment. KISS, or Occam's Razor for us diplomats, is sadly
I thought it was philosophers who reffered to Occams razor? OTOH using
the term Occam's razor instead of KISS would seem to be a contradiction
in terms ;-) Then again, perhaps not......I would like to think that
keeping it simple is synonymous with 'refined' and 'elegant', not
'crude' and 'coarse'.
I like Pascal's explanation of simplicity - "I apologize for this letter
being so long; I had no time to make it shorter". Simplicity is the
essence of elegance and refinement.
Your idea of being able to define your protocol is a strong one. I tend
to revert to HTTP these days only for practical reasons - it penetrates
firewalls without having to slug it out with system administrators.
A diversion. My daughter is working on embedded systems, in this case
RFID's and looking to develop secure encryption methods with simplicity
and elegance sufficient to run on the very small computational power
availalable on these devices. As we seek lower powered devices once
again we shall discover that a better algorithm always beats a bigger
hammer at solving the problem.
A further point. Simple and efficient methods have another major
advantage, they make the application scalable. A solution that is 500
times more efficient may show no initial advantage but be a blessing
when it can be expanded to 500 times the size of the clumsy one when the
limits of current technology are reached, or be an equal blessing when
it can be shrunk many times to take up less real estate.
JS
