[fpc-pascal] 3-tier database applications with FPC

[michael.vancanneyt at wisa.be]

On Wed, 19 Oct 2011, Leonardo M. Ramé wrote:

>> ________________________________
>> From: Graeme Geldenhuys <graemeg.lists at gmail.com>
>> To: FPC-Pascal users discussions <fpc-pascal at 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.vancanneyt at 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.