Synopse Open Source

DNS and LDAP are the two protocols on which the Internet and the Intranet are built.
Most of the time, you don't have to care about them. But sometimes, you need to access them directly, especially in a corporate environment.

We just introduced in our Open Source mORMot 2 framework two client units to access DNS and LDAP/CLDAP servers.
You can resolve IP addresses and services using DNS, and ask for information about your IT infrastructure using LDAP.

A recent poll on the Lazarus/FPC forum highlighted a fact: pascal coders are older than most coders. Usually, at our age, we should be managers, not developers. But we like coding in pascal. It is still fun after decades!
But does it mean that you should not use pascal for any new project? Are the language/compilers/libraries outdated?
In the company I currently work for, we have young coders, just out-of-school or still-in-school, which joined the team and write great code!

And a recent thread in this very same forum was about comparing languages to implement a REST server, in C#, Go, Scala, TypeScript, Elixir and Rust.
Several pascal versions are about to be contributed, one in which mORMot shines.

To ensure thread-safety, especially on server side, we usually protect code with critical sections, or locks. In recent Delphi revisions, we have the TMonitor feature, but I would rather trust the OS for locks, which are implemented using Windows Critical Sections, or POSIX futex/mutex.

But all locks are not born equal. Most of the time, the overhead of a Critical Section WinAPI or the pthread library is not needed.
So, in mORMot 2, we introduced several native locks in addition to those OS locks, with multi-read/single-write abilities, or re-entrancy.

Debug information can be generated by compilers, to contain symbols and source code lines. This is very handy to have a meaningful stack trace on any problems like exceptions, at runtime.

The problem is that debug information can be huge. New code style with generics tends to increase this size into a bloated way...
On Delphi, mormot2tests generates a 4MB .map file;
on FPC, mormot2tests outputs a 20MB .dbg file in DWARF.

For Delphi, we propose our own binary .mab format which reduces this 4MB .map file into a 290KB .mab file since mORMot 1.
Now mORMot 2 can reduce a FPC debug file of 20MB into a 322KB .mab file!
And this .mab information can just be appended to the executable for single-file distribution, if needed, during the build. No need to distribute two files, potentially with synchronization issues.

Last week, I committed new ASM implementations of our AES-PRNG, AES-CTR and AES-GCM for mORMot 2.
They handle eight 128-bit at once in an interleaved fashion, as permitted by the CTR chaining mode. The aes-ni opcodes (aesenc aesenclast) are used for AES process, and the GMAC of the AES-GCM mode is computed using the pclmulqdq opcode.

Resulting performance is amazing: on my simple Core i3, I reach 2.6 GB/s for aes-128-ctr, and 1.5 GB/s for aes-128-gcm for instance - the first being actually faster than OpenSSL!

I've uploaded two sets of slides from my presentations at EKON 22 : Object Pascal Clean Code Guidelines Proposal High Performance Object Pascal Code on Servers with the associated source code The WorkShop about "Getting REST with mORMot" has a corresponding new Samples folder in our  […]

In the last weeks/months, we worked a lot with FPC.
Delphi is still our main IDE, due to its better debugging experience under Windows, but we target to have premium support of FPC, on all platforms, especially Linux.

The new Delphi Linux compiler is out of scope, since it is heavily priced, its performance is not so good, and ARC broke memory management so would need a deep review/rewrite of our source code, which we can't afford - since we have FPC which is, from our opinion,  a much better compiler for Linux.
Of course, you can create clients for Delphi Linux and FMX, as usual, using the cross-platform client parts of mORMot. But for server side, this compiler is not supported, and will probably never be.

I've just updated the documentation part about the SOLID Design Principles.
The former blog article (almost 4 years old!) sounds like a bit deprecated now...
This is why I would extract here an updated version of this material.

Ensure you checked the corresponding part of the mORMot documentation, which is the updated reference, and probably the easiest to read - including links to all the other documentation.

The acronym SOLID is derived from the following OOP principles (quoted from the corresponding Wikipedia article):

• Single responsibility principle: the notion that an object should have only a single responsibility;
• Open/closed principle: the notion that "software entities ... should be open for extension, but closed for modification";
• Liskov substitution principle: the notion that "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” - also named as "design by contract";
• Interface segregation principle: the notion that "many client specific interfaces are better than one general purpose interface.";
• Dependency inversion principle: the notion that one should "Depend upon Abstractions. Do not depend upon concretions.". Dependency injection is one method of following this principle, which is also called Inversion Of Control (aka IoC).

If you have some programming skills, those principles are general statements you may already found out by yourself. If you start doing serious object-oriented coding, those principles are best-practice guidelines you would gain following.

They certainly help to fight the three main code weaknesses:

• Rigidity: Hard to change something because every change affects too many other parts of the system;
• Fragility: When you make a change, unexpected parts of the system break;
• Immobility: Hard to reuse in another application because it cannot be disentangled from the current application.

Just to share a commit of some interest to FPC/Lazarus users. Ondrej Pokorny (aka "reddwarf" in our forums) did send to us a nice implementation of our SynTaskDialog.pas unit, compatible with Lazarus. Since it is incompatible with the current state of the other mORMot UI units (which are  […]

There is a new player in town.
Since it has been written by Andreas Hausladen, the maintainer of the great Delphi IDE fix packs, this new JSON library is very promising.

And in fact, it is fast, and sounds pretty great!
Here are some numbers, compared with SuperObject, standard DBXJson, dwsJSON, QDAC and mORMot.
Please refer to previous benchmark articles about those libraries. We will now focus on JsonDataObjects.