"Trop c'est trop" - No Client-Server for XE3 PRO users

ab · 2012-08-28 06:13:56

Here is some unbelievable news retrieved from "Te Waka o Delphi" blog:

From XE3 onwards, your Delphi Professional EULA will prohibit you from using Delphi Professional for anything other than local data access.
If you want to build client/server database applications using Delphi Professional, you will be required to purchase a “Client/Server Add-On” pack.
This goes beyond the fact that you do not get (or can otherwise use or install) client/server drivers for the DBExpress or other “built in” data access frameworks, but extends even to 3rd party data access technologies.
That is, whatever you may be able to do or achieve – technically – using some 3rd party component or library with you Delphi Professional compiler, you cannot legally create a client/server application.
Never mind any 3rd party components or libraries, this same prohibition will apply even if you are using naked, unadorned Microsoft ADO.

Damn show-stopper for me.
Embarcadero is killing Delphi.

I can not believe this is not an abusive licensing clause.
Forbid someone to use a product for its own use was always hard to figure, but in this case it sounds infamous.
Could make sense to say that if you make more than 1,000 $ with their product, you will have to buy a Pro license, and that a Starter is not enough.
But imagine you want to create a Client-Server application for non-profit target (like a home app). You won’t be allowed to do it unless you buy an Entreprise version.
In the 21th century, pretty everything is connected, i.e. Client-Server. Even a browser start to behave like a server (via websocks and such).
Pretty abusive clause.
Delphi killer.

Damn show-stopper for me.

And now, you’ll have to pay for a lot of stuff you really don’t need nor use.

This leads us to a clear switch to FreePascalCompiler or good old Delphi 7/2007 for the server part, and something like SmartMobileStudio for the client GUI part (rich AJAX apps work on Win&Mac Desktop, iPhone, Android, and even Metro). Our framework is fully Unicode even before Delphi 2009, so we won’t need the overweight of Delphi 2009+.
‘Trop c’est trop’ as we say in France.

gerardus · 2012-08-28 07:41:06

Bonjour Arnaud,

It's a nice way to shoot themselves on the foot, and the message is clear: Embarcadero acknowledge Delphi market is a niche shrinking market, and they have to milk it to death before it disappears. They have been unable or unwilling to grow the user base, so the only way they found to expand their revenue is to make it more expensive, and they don't care if it kills the product.
If it is true, for me it's the end of a long relationship with Delphi.
About your framework, I doubt an EULA like this is valid in Europe, and it's probably not valid in the U.S. as well.
A third party component seller could loose his partner status by not abiding to the rule, but I think open source projects are safe. The problem is that this license will shrink Delphi user base even more.
I used FPC and Lazarus in a couple of small projects, it's time to give them another chance.

Cordialement,

Gerard.

ab · 2012-08-29 07:25:50

Sounds like if it has been confirmed by David Intersome, from Embarcadero.
See https://forums.embarcadero.com/message. … 576#486576

Very sad news...

@gerardus
You are probably right.
If this is a programmed death of Delphi, I think I'll switch to FPC sooner and later.
Delphi 7 is still my main IDE, with CnPack and other tweaks it is very productive.
FPC will add multi-OS targeting. I expect especially mORMot to serve data from cheap Linux boxes.
From the European POV, such a clause should be made abusive.
For Open Source project like ours, it may in fact do the contrary: people could be able to buy the starter edition, then use mORMot to implement full Client-Server and direct database access. Whereas third-party components sellers would be obliged to check the installed IDE version before installing the components.

Leander007 · 2012-08-29 17:48:44

I read the forum and people are untitled to be angry, with all WinRT mess (Microsoft "super idea") I was reading about few days ago, now Embercadero wants to win in stupidity (greed has no limits and no brain).

I'm already "mini supporting" Lazarus-FPC team (I bought the book "Lazarus the complete guide" ) even I don't use it already (I just tested it).
Do you have any plans to officially (not just partially) support mORMot for FPC? I believe that first target would be the Windows and that won't be so hard. Harder would be for Linux, which is very interesting target (as you already said it) for server part.

Last edited by Leander007 (2012-08-29 17:49:33)

ab · 2012-08-30 05:25:27

Most of the source code is already prepared for FPC (see all {$ifdef FPC} in the code).
It compiles, but there are some issues about RTTI retrieval.
Need to be fixed: should not be too much difficult.

I use the CodeTyphon distribution - from http://www.pilotlogic.com/sitejoom/index.php/codetyphon - which is very easy to install, has a lot of third-party components, and can create most cross-compilers directly from an easy interface.
It is amazing to compile the compiler and the IDE 100% from the sources.
Another world than Embarcadero!

And the Lazarus IDE is pretty usable. Compilation is slower than Delphi, but works fine and IDE learning curve is very small, when coming from Delphi IDE.

ab · 2012-08-30 15:52:14

Some good news?
http://delphitools.info/2012/08/30/poor … -reverted/

Stay tuned!
Perhaps they will listen to common sense (and customers)!

ab · 2012-09-06 18:21:52

The mORMot road-map has been updated.
See http://synopse.info/fossil/wiki?name=RoadMap

As you may have noticed, FPC 2.7 support is now officially envisaged.
Framework code already compiles, but need debugging on Windows.

Then cross-platform should be made available:
- Using FPC for Linux as server platform;
- And FPC/Lazarus/wxForms for Mac OS X, Windows and Linux clients.

We are a bit concerned by the XE3 "features", like platform drop or FireMonkey API inconsistency.

Our latest FPC / Lazarus evaluation was quite positive (using a CodeTyphon). Even if the compiler is a bit slower than Delphi (+ its Andreas' enhancements), it is quite productive and easy to use.
Having the A&T assembler syntax in the debugger instead of the usual Intel syntax is the most confusing change for me.

mpv · 2012-09-07 06:55:13

FPC support is a greate news! But one question - what about THttpServerGeneric descendants under Linux? I mean THttpApiServer (need http.sys) or THttpServer (need IOCP). If we do THttpServerGeneric without asynchronous IO we need to change architecture from fixed number of thread to unlimited thread pool (it's bad - every thread in current realization store database connection. creating many DB connection is very resource cost)? Or you have other idea?
For example my lovely HTTP server nginx use this models: http://nginx.org/en/docs/events.html

Also if we migrate to Linux we can do PostgreSQL direct support - under Linux it's a best production DB for now. Almost (but even better) as Oracle in performance on big databases (1Tb and up) but free and OpenSource.

Last edited by mpv (2012-09-07 08:28:45)

ab · 2012-09-07 09:13:50

For Linux, I used a FastCGI-based solution - with a lighttpd server (which uses IOCP pattern, just like nginx).
FastCGI is very efficient under Linux: local socket communications are pretty fast.

There is already a FastCGI unit prepared, but not debugged.
See http://synopse.info/fossil/finfo?name=S … Server.pas

Sounds like nginx also handle FastCGI protocol also.
See http://nginx.org/en/docs/http/ngx_http_ … odule.html

Yes, PostgreSQL direct support (via libpq library) could be a good idea.
The libpg API sounds pretty clear - see http://www.postgresql.org/docs/9.1/static/libpq.html
But I was not able to find any "batch array binding" feature, like we did with Oracle.

mpv · 2012-09-07 10:28:01

FastCGI is good idea. But as I look in current implementation it use only one thread. This means 10 times slowly compared to current multithread implementation via http.sys. I'm right? (then I not use THttpApiServer.Clone - is the same as via current FastCGI implementation - i got 700 RPS (request per second), then I set THttpApiServer.Clone(12) i got - 8800 RPS). For testing I use ApacheBench ( ab.exe

If we create 12 fastCGI app in pool then the question is shared data ( fSessions and fStaticData in our case).....

About nginx - yes, it's support FastCGI.

About Postgre:
closest analogue to bulk insert is COPY operation http://www.postgresql.org/docs/8.3/inte … -copy.html (in our case via STDIN)

Also in last version Postgre support JSON!! http://www.postgresql.org/docs/devel/st … -json.html. So we can get select result directly in JSON format - it's funny

Last edited by mpv (2012-09-07 11:57:19)

ab · 2012-09-07 12:18:53

Yes, current SQLite3FastCGIMainProc() implementation uses only one thread.
In fact, FastCGI expect only one server process per connection.

AFAIK you can configure the HTTP server (i.e. nginx / apache / lighttpd) to create several processes.
But you'll need to share a TSQLRestServer instance between FastCGI processes - which requires another Client-Server layer, I suspect.
The SQLite3FastCGIMainProc() processes should work as proxies/gateways, in this case. And the main TSQLRestServer should be e.g. a service, accessible via named pipes or sockets (under Windows).

Perhaps the plain multi-threaded THttpServer class (using plain OS sockets and a TSynThreadPoolTHttpServer thread pool), accessed by the main HTTP server via a local proxy - e.g. http://wiki.nginx.org/HttpProxyModule - would scale better than FastCgi. This THttpServer class was defined to be not Windows-bound, so would work on Linux with minor modifications - it should be working with CrossKylix already.
IOCP would be implemented at the main HTTP server level (nginx / lighttpd), then our THttpServer would be called using multiple threads (if the proxy module has several instances or is configured accordingly).

For Linux, my previous applications where using CrossKylix to create server executables, with great success.
CrossKylix compiles very efficient Delphi 7 level ELF executables for Linux.

PG COPY operation is less attractive that the ODBC / Oracle array DML features.
We may test ODBC connection at first. Perhaps the ODBC layer is not too consuming.

mpv · 2012-09-07 14:55:58

You are right about nginx proxy. I use nginx as proxy and load balance with great success in real project. In my current project I use nginx for static files and proxy for mORMot server. If THttpServer become compatible with FPC I will try to use it with nginx proxy - this better as for me than single thread FastCGI solution.
But I don't understand how it possible (use THttpServer under linux) - TSynThreadPool use IOCP as i see (CreateIoCompletionPort TSynThreadPool .Initialize). Some wrapper exist in FPC for this call? Or under Linux you made other realization?

Last edited by mpv (2012-09-07 15:01:44)

ab · 2012-09-07 16:14:22

You are right, of course: TSynThreadPool uses IOCP under Windows.

I think we will at first rely on a "classic" TThread list under Linux, then migrate to some better solution if we find out that it is not responsive enough.

It will always be better than a single-process FastCGI solution.

mpv · 2012-10-13 12:58:47

Just for information - today I came across SCGI http://en.wikipedia.org/wiki/Simple_Com … _Interface. IMHO a very good candidate for pure pascal version of TFastCGIServer. And IMHO more KISS and mORMot'ing compared to fastCGI

ab · 2012-10-14 07:28:45

SCGI sounds indeed easier to implement, but also somewhat slower.

Main benefit is that you can define as many server as you want per process, which is compatible with out TSQLRestServer expectations.
But IMHO main drawback is that it closes the connection after each request, some should probably be slower for multiple small requests.

mORMot Open Source

#1 2012-08-28 06:13:56

"Trop c'est trop" - No Client-Server for XE3 PRO users

#2 2012-08-28 07:41:06

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#3 2012-08-29 07:25:50

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#4 2012-08-29 17:48:44

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#5 2012-08-30 05:25:27

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#6 2012-08-30 15:52:14

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#7 2012-09-06 18:21:52

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#8 2012-09-07 06:55:13

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#9 2012-09-07 09:13:50

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#10 2012-09-07 10:28:01

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#11 2012-09-07 12:18:53

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#12 2012-09-07 14:55:58

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#13 2012-09-07 16:14:22

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#14 2012-10-13 12:58:47

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

#15 2012-10-14 07:28:45

Re: "Trop c'est trop" - No Client-Server for XE3 PRO users

Board footer