The EKON 29 Konference in Dusseldorf just ended.

Nice year, with a lot of AI talks.
To keep the pressure low, I did not talk about AI, but gave 3 sessions and 1 workshop about mORMot. Here are the slides I used.
2025-10-29
2025-10-29. Open Source › mORMot Framework
The EKON 29 Konference in Dusseldorf just ended.

Nice year, with a lot of AI talks.
To keep the pressure low, I did not talk about AI, but gave 3 sessions and 1 workshop about mORMot. Here are the slides I used.
2024-01-01
2024-01-01. Open Source › mORMot Framework
Last year 2023 was perhaps not the best ever, and, just after Christmas, we think about all people we know still in war or distress.
But in the small mORMot world, 2023 was a fine millesima. A lot of exciting features, a pretty good rank in benchmarks, and a proof of being ready for the next decade.

For this new year, we would like to introduce you to a new mORMot baby: the mget command line tool, a HTTP/HTTPS web client with peer-to-peer caching.
It is just a wrapper around a set of the new PeerCache feature, built-in the framework web client class - so you can use it in your own projects if you need to.
2022-12-28
2022-12-28. Open Source › mORMot Framework
This is perhaps the last new feature of mORMot 2 before its first stable release: a very efficient custom URI routing for our HTTP/HTTPS servers.

At ORM and SOA level, there is by-convention routing of the URI, depending on the ORM table, SOA interface and method, and TOrmModel.Root value. Even for our MVC web part, we rely on a /root/ URI prefix, which may not be always needed.
Relying on convention is perfect between mORMot clients and servers, but in some cases, it may be handy to have something smoother, e.g. to publish a truly REST scheme.
We introduced two routing abilities to mORMot 2, with amazing performance (6-12 million parsings per CPU core), via a new THttpServerGeneric.Route property:
/root/interface.method layout, or to a MVC web page;Article edited on 28th December:
Fixed performance numbers (much higher than reported), and introduced latest source changes.
2022-07-09
2022-07-09. Open Source › mORMot Framework
Since the beginning, we delegated the TLS encryption support to a reverse proxy server, mainly Nginx. Under Windows, you could setup the http.sys HTTPS layer as usual, as a native - even a bit complicated - solution.
Nginx has several advantages, the first being a proven and efficient technology, with plenty of documentation and configuration tips. It interfaces nicely with Let's Encrypt, and is very good for any regular website, using static content and PHP. This very blog and the Synopse web site is hosted via Ngnix on a small Linux server.

But in mORMot 2, we introduced a new set of asynchronous web server classes. So stability and performance are not a problem any more. Some benchmarks even consider this server to be faster than nginx (the stability issue mentioned in this post has been fixed in-between).
We just introduced TLS support of our socket-based servers, both the blocking and asynchronous classes. It would use OpenSSL if available, or the SChannel API layer of Windows. Serving HTTPS or WSS with a self-signed certificate is just a matter of a single parameter now, and performance seems pretty good, especially with OpenSSL.
2022-05-21
2022-05-21. Open Source › mORMot Framework
The HTTP server is one main part of any SOA/REST service, by design.
It is the main entry point of all incoming requests. So it should better be stable and efficient. And should be able to scale in the future, if needed.

There have always been several HTTP servers in mORMot. You can use the HTTP server class you need.
In mORMot 2, we added two new server classes, one for publishing over HTTP, another able to upgrade to WebSockets. The main difference is that they are fully event-driven, so their thread pool is able to scale with thousands of concurrent connections, with a fixed number of threads. They are a response to the limitations of our previous socket server.
2021-05-14
2021-05-14. Open Source › mORMot Framework
HTTP(S) is the main protocol of the Internet.
We enhanced the mORMot 2 socket client to push its implementation into more use cases. The main new feature is perhaps WGET-like processing, with hashing, resuming, console feedback, and direct file download.

2020-08-11
2020-08-11. Open Source › mORMot Framework
For several reasons, only plain ASCII characters are accepted in Web URIs. Other characters should be escaped with % and the hexadecimal value of its code.

The tilde character ~ is not needed to be escaped... at least in theory... because in practice most code expects it...
A journey into confusing RFCs...
2014-11-18
2014-11-18. Open Source › Open Source libraries
For mORMot, we developed a fully feature direct access layer to any RDBMS, implemented in the SynDB.pas unit.
You can use those SynDB classes to execute any SQL statement,
without any link to the framework ORM.
At reading, the resulting performance is much higher than using the standard
TDataSet component, which is in fact a true performance
bottleneck.
It has genuine features, like
column access via late-binding,
an innovative ISQLDBRows interface, and ability to directly access
the low-level binary buffers of the database clients.

We just added a nice feature to those classes: the ability to access
remotely, via plain HTTP, to any SynDB supported database!
2014-08-16
2014-08-16. Open Source › mORMot Framework
You certainly noticed that WebSocket is the current
trendy flavor for any modern web framework.
But does it scale? Would it replace HTTP/REST?
There is a feature
request ticket about them for mORMot, so here are some thoughts -
matter of debate, of course!
I started all this by answering a StackOverflow
question, in which the actual answers were not accurate enough, to my
opinion.
From my point of view, Websocket - as a protocol - is some kind of monster.

You start a HTTP stateless connection, then switch to WebSocket
mode which releases the TCP/IP dual-direction layer, then you may switch later
on back to HTTP...
It reminds me some kind of monstrosity, just like encapsulating everything over
HTTP, using XML messages... Just to bypass the security barriers... Just
breaking the OSI layered
model...
It reminds me the fact that our mobile phone data providers do not use
broadcasting for streaming audio and video, but regular Internet HTTP servers,
so the mobile phone data bandwidth is just wasted when a sport event occurs:
every single smart phone has its own connection to the server, and the same
video is transmitted in parallel, saturating the single communication
channel... Smart phones are not so smart, aren't they?
WebSocket sounds like a clever way to circumvent a
limitation...
But why not use a dedicated layer?
I hope HTTP 2.0 would allow
pushing information from the server, as part of the standard... and in one
decade, we probably will see WebSocket as a deprecated
technology.
You have been warned. Do not invest too much in WebSockets..
OK. Back to our existential questions...
First of all, does the WebSocket protocol scale?
Today, any modern single server is able to server millions of clients at
once.
Its HTTP server software has just to be is Event-Driven (IOCP)
oriented (we are not in the old Apache's one connection = one
thread/process equation any more).
Even the HTTP server built in Windows (http.sys - which is used in
mORMot) is IOCP oriented and very efficient (running in kernel
mode).
From this point of view, there won't be a lot of difference at scaling between
WebSocket and a regular HTTP connection. One TCP/IP connection
uses a little resource (much less than a thread), and modern OS are optimized
for handling a lot of concurrent connections: WebSocket and HTTP
are just OSI 7 application layer protocols, inheriting from this TCP/IP
specifications.
But, from experiment, I've seen two main problems with WebSocket:
2014-08-11
2014-08-11. Open Source › mORMot Framework
Current version of the main framework units target only Win32 and Win64 systems.
It allows to make easy self-hosting of mORMot servers for local
business applications in any corporation, or pay cheap hosting in the Cloud,
since mORMot CPU and RAM expectations are much lower than a regular
IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need
to create clients for platforms outside the Windows world, especially
mobile devices.

A set of cross-platform client units is therefore available in the
CrossPlatform sub-folder of the source code repository. It allows
writing any client in modern object pascal language, for:
This series of articles will introduce you to mORMot's Cross-Platform abilities:
Any feedback is welcome in our forum, as usual!
2014-08-11. Open Source › mORMot Framework
Current version of the main framework units target only Win32 and Win64 systems.
It allows to make easy self-hosting of mORMot servers for local
business applications in any corporation, or pay cheap hosting in the Cloud,
since mORMot CPU and RAM expectations are much lower than a regular
IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need
to create clients for platforms outside the Windows world, especially
mobile devices.

A set of cross-platform client units is therefore available in the
CrossPlatform sub-folder of the source code repository. It allows
writing any client in modern object pascal language, for:
This series of articles will introduce you to mORMot's Cross-Platform abilities:
Any feedback is welcome in our forum, as usual!
2014-08-11. Open Source › mORMot Framework
Current version of the main framework units target only Win32 and Win64 systems.
It allows to make easy self-hosting of mORMot servers for local
business applications in any corporation, or pay cheap hosting in the Cloud,
since mORMot CPU and RAM expectations are much lower than a regular
IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need
to create clients for platforms outside the Windows world, especially
mobile devices.

A set of cross-platform client units is therefore available in the
CrossPlatform sub-folder of the source code repository. It allows
writing any client in modern object pascal language, for:
This series of articles will introduce you to mORMot's Cross-Platform abilities:
Any feedback is welcome in our forum, as usual!
2014-08-11. Open Source › mORMot Framework
Current version of the main framework units target only Win32 and Win64 systems.
It allows to make easy self-hosting of mORMot servers for local
business applications in any corporation, or pay cheap hosting in the Cloud,
since mORMot CPU and RAM expectations are much lower than a regular
IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need
to create clients for platforms outside the Windows world, especially
mobile devices.

A set of cross-platform client units is therefore available in the
CrossPlatform sub-folder of the source code repository. It allows
writing any client in modern object pascal language, for:
This series of articles will introduce you to mORMot's Cross-Platform abilities:
Any feedback is welcome in our forum, as usual!
2014-01-10
2014-01-10. Open Source › mORMot Framework
Our Synopse mORMot Framework was designed in accordance with
Fielding's REST
architectural style without using HTTP and without interacting with the
World Wide Web.
Such Systems which follow REST principles are often referred to as
"RESTful".

Optionally, the Framework is able to serve standard HTTP/1.1 pages over the
Internet (by using the mORMotHttpClient / mORMotHttpServer units
and the TSQLHttpServer and TSQLHttpClient classes),
in an embedded low resource and fast HTTP server.
2014-01-10. Open Source › mORMot Framework

There are 5 basic fundamentals of web which are leveraged to create REST services:
2014-01-05
2014-01-05. Open Source › mORMot Framework
In addition to regular HTTPS flow encryption, which is not easy to setup due to the needed certificates, mORMot proposes a proprietary encryption scheme. It is based on SHA-256 and AES-256/CTR algorithms, so is known to be secure.

You do not need to setup anything on the server or the client configuration,
just run the TSQLHttpClient and TSQLHttpServer
classes with the corresponding parameters.
2013-09-19
2013-09-19. Pascal Programming
We all know that the first Delphi for Android was just released...
I just found out an amazing alternative, using native Android controls, and FPC/Lazarus as compiler and IDE.

It creates small .apk file: only 180 KB, from my tests!
It makes use of direct LCL access of Android native controls, so it is a great sample.
2013-09-10
2013-09-10. Open Source › mORMot Framework
We tried to make mORMot at the same time fast and safe, and able to
scale with the best possible performance on the hardware it runs on.
Multi-threading is the key to better usage of modern multi-core CPUs, and also
client responsiveness.
As a result, on the Server side, our framework was designed to be thread-safe.

On typical production use, the mORMot HTTP server will run on its
own optimized thread pool, then call the TSQLRestServer.URI
method. This method is therefore expected to be thread-safe, e.g. from the
TSQLHttpServer. Request method. Thanks to the RESTful approach of
our framework, this method is the only one which is expected to be thread-safe,
since it is the single entry point of the whole server. This KISS design ensure
better test coverage.
Let us see now how this works, and publish some benchmarks to test how efficient it has been implemented.
2013-09-04
2013-09-04. Open Source › mORMot Framework
In mORMot, the http.sys kernel
mode server can be defined to serve HTTPS secure content.
Yes, mORMots do like sophistication:

When the aUseSSL boolean parameter is set for
TSQLHttpServer.Create() constructor, the SSL layer will be enabled
within http.sys.
Note that useHttpSocket kind of server does not offer SSL
encryption yet.
We will now define the steps needed to set up a HTTPS server in mORMot.
2013-07-04
2013-07-04. Open Source › mORMot Framework
In mORmot applications, all the client communication is executed by
default in the current thread, i.e. the main thread for a typical GUI
application.
This may become an issue in some reported
environments.
![]()
Since all communication is performed in blocking mode, if the
remote request takes long to process (due to a bad/slow network, or a long
server-side action), the application may become unresponsive, from the end-user
experience.
Even Windows may be complaining about a "non responsive application",
and may propose to kill the process, which is far away from an expected
behavior.
In order to properly interacts with the user, a OnIdle property
has been defined in TSQLRestClientURI, and will change the way
communication is handled.
If a callback event is defined, all client communication will be processed in a
background thread, and the current thread (probably the main UI thread) will
wait for the request to be performed in the background, running the
OnIdle callback in loop in the while.
« previous entries - page 1 of 2