On Wed, 19 Oct 2011, Leonardo M. Ramé wrote:
________________________________
From: Graeme Geldenhuys <graemeg.li...@gmail.com>
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Sent: Wednesday, October 19, 2011 8:25 AM
Subject: Re: [fpc-pascal] 3-tier database applications with FPC
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.
Is parsing JSON any faster than XML? Sorry if this is a stupid
question, but I know near zero about JSON.
I created a FastCGI based server that handles JSON requests from a
Win32/Linux GUI app, that uses a custom made ORM similar to tiOPF and it
works really fast, even on slow-long distance networks. I never had to do
this, but as most modern http servers support gzip compression, one
alternative to binary formats is to enable compression on server side, and
decompress on client side.
This approach has the advantage of JSON readability and the small size of
binary format.
That's exactly what we do also.
But in the case of large packages (we have datasets of 30.000 records),
the JSON is really slow.
The browser chokes already on a dataset of 3000 records, when using ExtJS =-)
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
