On Wed, 19 Oct 2011, Graeme Geldenhuys wrote:
On 2011-10-19 11:36, michael.vancann...@wisa.be wrote:
Out of the box: no.
OK, thanks. Do you know if TClientDataset has improved at all?
Midas is written in C++, so that's not going to happen.
I didn't know that.
OTOH the web-development part has resulted in a ready-to-use packet transport
layer. It's inefficient though, since it uses JSON or XML, but that can
easily be adapted to support a 'binary' packet.
I just finished watching a CodeRage 5 Datasnap demo. The guy said that
XML packet transport is extremely slow (because XML is generally hard to
parse). Simply changing to CSV packet format gave a 20x speed
improvement, but obviously CSV is not self-describing.
It depends on a number of factors.
I did extensive testing of the speed difference in XML and binary messaging.
One of the conclusions was that you can gain an overall speed improvement of a
factor 6 when switching from XML to binary messaging. Not using HTTP but a
self-made TCP/IP protocol gets you another factor.
SOAP over HTTP (the standard for webservices) has the incredible advantage
that it is cross-platform, and meanwhile any language can handle it.
The incredible downside is that it is slow and bulky.
Our client/server apps used HTTP/SOAP it when we just started. It took us
less than a week to realize this was a very bad idea, so we switched to
TCP/IP and binary messages. Never looked back since.
(and this was before I did the extensive testing)
Is parsing JSON any faster than XML? Sorry if this is a stupid
question, but I know near zero about JSON.
Yes it is.
It's much less verbose also, which means the transported packets
are much smaller.
OK, so it seems worth my while to port the tiOPF Remote Persistence
Layer to FPC+Synapse (or maybe lNet) then. Based on an old message from
Peter Hinrichsen, tiOPF can take care of everything for me, without 3rd
party components or libraries, including some state information. He also
mentioned that [at the time of his message] it was well unit tested and
already used for 4 years in a production environment. The current tiOPF
Remote Persistence Layer uses Indy's HTTP client & server components and
has two data packet formats it supports (one being more compressed).
I'll dive into that code then and see what I can manage with FPC.
If you do, then I'd be very interested in hearing about your progress.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
