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

[Leonardo M. Ramé]

----- Original Message -----

> From: "michael.vancanneyt at wisa.be" <michael.vancanneyt at wisa.be>
> To: Leonardo M. Ramé <martinrame at yahoo.com>; FPC-Pascal users discussions <fpc-pascal at lists.freepascal.org>
> Cc: 
> Sent: Wednesday, October 19, 2011 11:03 AM
> Subject: Re: [fpc-pascal] 3-tier database applications with FPC
> 
> 
> 
> 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.
>

In those cases, we use pagination. We allways ask for record 1-100, 101-200, and so on.
 
Leonardo M. Ramé
http://leonardorame.blogspot.com