Synopse Open Source

You may have noticed that the OpenSSL 1.1.1 series will reach End of Life (EOL) next Monday...
Most sensible options are to switch to 3.0 or 3.1 as soon as possible.

Of course, our mORMot 2 OpenSSL unit runs on 1.1 and 3.x branches, and self-adapt at runtime to the various API incompatibilities existing between each branch.
But we also discovered that switching to OpenSSL 3.0 could led into big performance regressions... so which version do you need to use?

For most projects, we want to be able to pass some custom values when starting it.
The command line is then used to add this additional information.

We have ParamStr and ParamCount global functions, enough to retrieve the information. You may also use FindCmdLineSwitch for something more easy to work with.
The Lazarus RTL offers some additional methods like hasOption or getOptionValue or checkOptions in its TCustomApplication class. Their are better, but not so easy to use, and not available on Delphi.

We just committed a new command line parser to our Open Source mORMot 2 framework, which works on both Delphi and FPC, follows both Windows and POSIX/Linux conventions, and has much more features (like automated generation of the help message), in an innovative and easy workflow.

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.

The more I think of it, the more I am convinced it is time to change how the framework is versioned.
We have version 1.18 since years... difficult to follow... time to upgrade!

I would like to upgrade mORMot to version 2 - with a major refactoring.

There are still some days to join EKON 23 conferences with the reduced price!

I will make 2 sessions, and 1 workshop, in English (my German is not good enough), about practical project design and mORMot.
If you find DDD is a bit too much for you, but still want to write clean code, check this!

In order to follow best practice, our .private key files are always protected by a password.  A random value with enough length and entropy is always proposed by the ECC tool when a key pair is generated, and could be used directly.
It is always preferred to trust a computer to create true randomness (and SynCrypto.pas's secure TAESPRNG was designed to be the best possible seed, using hardware entropy if available), than using our human brain, which could be defeated by dictionary-based password attacks.
Brute force cracking would be almost impossible, since PBKDF2_HMAC_SHA256 Password-Based Key Derivation Function with 60,000 rounds is used, so rainbow tables (i.e. pre-computed passwords list) will be inoperative, and each password trial would take more time than with a regular Key Derivation Function.

The issue with strong passwords is that they are difficult to remember. If you use not pure random passwords, but some easier to remember values with good entropy, you may try some tools like https://xkpasswd.net/s which returns values like $$19*wrong*DRIVE*read*61$$.
But even then, you will be able to remember only a dozen of such passwords. In a typical public key infrastructure, you may create hundredths of keys, so remembering all passwords is no option for an average human being as (you and) me.

At the end, you end up with using a tool to store all your passwords (last trend is to use an online service with browser integration), or - admit it - store them in an Excel document protected by a password. Most IT people - and even security specialists - end with using such a mean of storage, just because they need it.
The weaknesses of such solutions can be listed:

• How could we trust closed source software and third-party online services?
• Even open source like http://keepass.info/help/base/security.html may appear weak (no PBKDF, no AFSplit, managed C#, SHA as PRNG);
• The storage is as safe as the "master password" is safe;
• If the "master password" is compromised, all your passwords are published;
• You need to know the master password to add a new item to the store.

The ECC tool is able to work in "cheat mode", storing all .private key files generated passwords in an associated .cheat local file, encrypted using a cheat.public key.

As a result:

• Each key pair will have its own associated .cheat file, so you only unleash one key at a time;
• The .cheat file content is meaningless without the cheat.private key and its master password, so you can manage and store them together with your .private files;
• Only the cheat.public key is needed when creating a key pair, so you won't leak your master password, and even could generate keys in an automated way, on a distant server;
• The cheat.private key will be safely stored in a separated place, only needed when you need to recover a password;
• It uses strong File Encryption, with proven PBKDF, AFSplit, AES-PRNG, and ECDH/ECIES algorithms.

We have seen previously how the ORM part of the framework is able to provide an Audit Trail for change tracking.
It is a very convenient way of storing the change of state of the data.

On the other side, in any modern SOA solution, data is not at the center any more, but services.
Sometimes, the data is not stored within your server, but in a third-party Service-Oriented Architecture (SOA).
Being able to monitor the service execution of the whole system becomes sooner or later mandatory.

Our framework allows to create an Audit Trail of any incoming or outgoing service operation, in a secure, efficient and automated way.

One year ago, we published a set of slides about the main concepts implemented by our framework. Mainly about ORM (and ODM), NoSQL, JSON, SOA, MVC (and MVVM), SOLID, DDD, CQRS and some patterns like Stubs, Mocks, Factory, Repository, Unit-Of-Work. Worth a look, if you want to find out the benefits  […]

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.

As stated during TSQLRecord fields definition, the ORM is able to maintain a revision number for any TSQLRecord table, so that it the table may be easily synchronized remotely by another TSQLRestServer instance.
If you define a TRecordVersion published property, the ORM core will fill this field just before any write with a monotonically increasing revision number, and will take care of any deletion, so that those modifications may be replayed later on any other database.

This synchronization will work as a strict master/slave replication scheme, as a one-way on demand refresh of a replicated table.
Each write operation on the master database on a given table may be easily reflected on one or several slave databases, with almost no speed nor storage size penalty.