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

[michael.vancanneyt at wisa.be]

On Wed, 19 Oct 2011, Graeme Geldenhuys wrote:

> 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.

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.