Revision 2.x of the framework

ab · 2020-03-03 19:10:55

It is time to change how the framework is versioned.
We have version 1.18 since years... time to upgrade!

I would like to upgrade mORMot to version 2.

1. Switch to Semantic Versioning - see https://semver.org
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
The idea would be to have 2.# minor version every month, with patches in-between. A monthly minor upgrade allow to have new features included quick enough to be interresting.

2. mORMot 2.0.0 would induce incompatible API changes.
I would like:
2.1. To remove all reminicence of the "SQLite3 framework", e.g. the SQLite3 sub-folder.
2.2. Try to split SynCommons.pas and mORMot.pas units into smaller units. Putting e.g. the raw JSON process or RTTI in some external unit.
2.3. Introduce some high-level classes and units, perhaps as (why-not?) some non-visual TComponent version of our classes. Keeping existing low-level classes, which are stable and full of features - but difficult to adopt.
2.4. Get rid of Delphi 5 official compatibility, and focus on FPC as main target - but perhaps officially maintaining only a few version of Delphi (2007/XE7/10.3?) - with other version maintained by contributors.

Any feedback is welcome!

Edit: I have made a Google Survey to have your insights!
Please check https://forms.gle/Hxa3yT6XQVvVNB3h9

macfly · 2020-03-03 20:13:09

Great news!

I completely agree to remove the SQLite3 folder. I believe it should cause a lot of confusion for those who are starting, mainly because it gives the impression that the framework supports only this database.

Breaking SynCommons.pas would also be great.

Creating components even if not visual, in my view is unnecessary. I don't know if it's worth the effort. IMHO

sakura · 2020-03-03 20:19:52

ab wrote:

It is time to change how the framework is versioned.

Aye :-)

ab wrote:

2. mORMot 2.0.0 would induce incompatible API changes.

Ouch, but happens from time to time.

ab wrote:

2.1. To remove all reminicence of the "SQLite3 framework", e.g. the SQLite3 sub-folder.

As long as SQLite stays supported, I think no one would ever be sad about a folder going away.

ab wrote:

2.2. Try to split SynCommons.pas and mORMot.pas units into smaller units. Putting e.g. the raw JSON process or RTTI in some external unit.

That certainly will be interessting, as we all have to start finding things again. But I hear you, those units are awfully big and likely hard to maintain. Certainly, giving you awesome JSON stuff its own realm to live in is a great step.

ab wrote:

2.3. Introduce some high-level classes and units, perhaps as (why-not?) some non-visual TComponent version of our classes. Keeping existing low-level classes, which are stable and full of features - but difficult to adopt.

Not sure what the components would provide really, and likely would never use them, but I think almost no one is using everything of the framework, so they would not hurt. Just can't really see the benefit of those. Then again, I promote using web interfaces, which would not need them anyways.

ab wrote:

2.4. Get rid of Delphi 5 official compatibility, and focus on FPC as main target - but perhaps officially maintaining only a few version of Delphi (2007/XE7/10.3?) - with other version maintained by contributors.

Not using FPC, but gladly keep testing on D10.3 and coming versions. As you use FPC for your work since a few years, I am sure, it's been your focus anyways, so getting rid of a couple old versions should be fine, I'd say.

And as your documentation is better than almost any other out there, I am not scared of the coming changes.

Regards,
Daniel

P.S.: Do you have a time frame on that?

Last edited by sakura (2020-03-03 20:21:52)

mdbs99 · 2020-03-03 20:20:07

That is good.

I agree about almost all, especially about 2.2 — even it is easy using only one unit like SynCommons with "all included", it could be difficult to maintain the code because its size and bugs on IDE.

About 2.4, Although, I completely agree to focus on FPC as main target, I'm concerned about Delphi 7 compatibility, as I still have some systems on it.

urhen · 2020-03-03 20:37:56

Sounds good to me!

Splitting the huge units into smaller ones is a very good idea - maybe splitted into use cases (JSON, Converters, Helpers, ...). Then one could also pick only specific (small) units for other projects like your fast TDictionary implementation.
If you want to support only newer compilers (I'm happy with that - no need to support 10+ year old compilers and work-around bugs/missing features etc all the time) you could use units with dots (no idea which Delphi versions support it): SynCommons.JSON, SynCommons.Converter, etc.
Supporting newer compilers only would probably also remove a lot of code and IFDEFs :-)

Last edited by urhen (2020-03-03 20:39:35)

mpv · 2020-03-03 20:42:21

Nice!
Dropping support for old Delphi definitionally made code more clean.
May be also a git as a main repository (to prevent periodical sync problems)?

BTW size of SynCommons is not a problem for Lazarus, only for Delphi.

George · 2020-03-03 21:05:30

Agree. It's time to move on)
Instead of non UI component wrappers, would be nice to refresh documentation. High level classes is good idea too.

Maybe this helps: https://docusaurus.io
https://mikro-orm.io/docs/defining-entities

Also i agree about opinion to drop old compiler support. Not worth to waste time.
FPC is good choice as main target, because, embarcadero actively ruining Delphi community, which are almost gone, unfortunately.

Would be nice to beat .net core and support windows, linux and mac.
FPC and high level classes can help with that.

May be also a git as a main repository (to prevent periodical sync problems)?

+1

Last edited by George (2020-03-03 21:08:59)

macfly · 2020-03-03 21:14:07

+1 for git as primary repo.

darianmiller · 2020-03-03 21:54:57

Definitely agree on splitting things up and giving some more options to highlight stand-alone components. You have a ton of functionality in the source, and a huge amount of documentation, but much of the functionality is lost by the casual onlooker. If they aren't in the market for an ORM, the may certainly be interested in the other functionality that is available.

pvn0 · 2020-03-04 08:40:32

I think it's a great idea, especially the part about splitting into smaller source files.

mpv wrote:

May be also a git as a main repository (to prevent periodical sync problems)?

I thought fossil has good support for syncing back and forth from git?

MC · 2020-03-04 13:08:29

These proposals seem to me to be heading in the right direction.
All my projects are developed under Delphi 7.
I use third party components that today are not compatible with FPC.

EMartin · 2020-03-04 13:28:36

I agree at all, except excluding Delphi 7 because all our projects are developed with it and, unfortunately, with third party components. I initiated conversations with my boss for migrating UI to web and use FPC as tool for backend development, but that's something that takes time. Maybe support for Delphi 7 for a few years (you decide how long) will be fantastic.

Excellent idea of use the semantic versioning.

Units splitting should be for functionality in my opinion, for example SynJSON with all related support for JSON handling.

Maybe this thread shoud be post as "sticky".

Last edited by EMartin (2020-03-04 13:30:07)

ab · 2020-03-04 14:50:32

@Emartin OK - I would keep Delphi 7 compatibility I guess. Isn't it possible use Delphi 2007 instead? It is a bit more stable and has some nice enhancements - like inlining.
But get rid of Delphi 5, and only maintain some well identified versions, including the latest Delphi revision. No Delphi Linux support in the roadmap (FPC is just better here).
Sadly I can't put the thread as "sticky" - bug in the forum code.

Documentation is already in a markdown-like format (closer to RTF in fact), and maintained within the source code. See https://synopse.info/fossil/finfo?name= … mework.pro
It has an unique system of graph generation, and also source code type definitions with comments extraction of all units documentation. Moving to something else would need a full rewrite, with less features... which I don't like much.
In practice, document generation may be enhanced by spliting the generated doc into several HTML pages, instead of a huge one - need to hack our SynProject tool for this.

The 'non-visual component' part was to ease adaption from Delphi RAD users: creating a data module, putting some mORMot components in there (RestServer, HttpServer, SOA, ORM) then define some properties and events to work in the IDE...
What I could at least for mORMot 2 is extract the SOA and ORM features from TSQLRest class, which is a bit bloated and not following the SRP.

I don't like github much. Fossil is just a nicer tool to me. The github commit diff display is just a joke: it doesn't show more than a few dozen modifications... Whereas fossil diff view has no problem with MB of diffs.
The latest Fossil version includes a basic forum feature, which could be nice to have a single website for all. And self-hosted.Not at Micro$oft's...
I would keep the github repository as a mirror to Fossil - but fixing the "rsynch bug" I am currently facing, by writing some pascal code to do the synch.

I will keep this thread open for a few days.
Don't hesitate to come back if you have any idea of wishes...

Vitaly · 2020-03-04 16:13:12

I also join others, especially in parts of giving up supporting old compilers and splitting huge units. It will be great!

My only tiny wish is to try to name new units in a more obvious way. Like @EMartin suggested as a sample.
The problem is that sometimes I forget which unit contains some particular function/type (or a set of functions/types) and I have to check SynCommons, then mORMot, then SynTable...
But I think, that Arnaud already has a proper idea for splitting and naming, so I believe everything will be fine

EMartin · 2020-03-04 16:24:10

Thanks @ab, my intention is move to FPC but out base code is huge and much UI with DevEx and other visual third party components, all these tasks take time and we are very small team. We have not Delphi 2007 license.

Greg0r · 2020-03-04 16:29:28

1) Forget about older Delphi compilers
Minimum supported XE4 or XE7 (personally I would go with Tokyo 10.2 as minimum)
At least if possible forget all before XE4

Waste of energy to maintain very old or very buggy/outdated Delphis
This energy could be spend on development new things/improving current instead of patching vendor bugs.
Aside from the topic point:
I never understand moneygrubbers who create sell their software make money on it and the same cannot spend some bucks to support creators.
Ok, maybe EMB policy and quality is far far away from beeing good anyway c'mon spending money on new compiler once a 5 years should not be big pain.
Nobody telling that you should have sub and new twice or one per year.
For those who love to be free so much - yes please, you have Lazaurs and FPC - good luck.

Now there is even stonger argument for getting rid of Old Delphi - Emb offers FREE compilers for free low income usage.
This is another argument against supporting very old.

2) SQLite object compilation - re-check which compiler produces the fastest/most realiable(least buggy) obj code:
BCC5.5 vs XE7 vs RIO 10.3.3 vs MS C++ (with coff conversion)
http://rvelthuis.de/articles/articles-cobjs.html

3) Add Argon2id, Argon2, Bcrypt/Scrypt hashing/key der.

4) Add AES GCM mode cipher,

5) Implement native 7-zip compression LZMA2, beside current solutions, native without external dlls based on c objects.

Last edited by Greg0r (2020-03-04 16:36:51)

urhen · 2020-03-04 20:15:18

Greg0r wrote:

1) Forget about older Delphi compilers
Minimum supported XE4 or XE7 (personally I would go with Tokyo 10.2 as minimum)
At least if possible forget all before XE4
Waste of energy to maintain very old or very buggy/outdated Delphis
This energy could be spend on development new things/improving current instead of patching vendor bugs.

You're absolutely right and I don't see why ab should spend his time on supporting old compilers just because some company's missed to upgrade their compiler for almost 20 years! They didn't spend many for 20 years and ab gives us an awesome product for free - so where is all the money from the company going to?
And mORMot as it is now works fine without flaws. If you use an old compiler, stay with the old mORMot version....or better, spend some money to move to recent compiler or even better, FPC!

EDIT:
some wishes:
- full TCP client with SSL support through OpenSSL (or similar vendors)
- more feature/code up-streaming to FPC (thats what open-source is all about , mORMot uses FPC trunk anyway) and Delphi could use plain pascal implementation as FPC is the main target and the fast assembly optimizations also improve the program in other parts

Last edited by urhen (2020-03-04 20:22:23)

edwinsn · 2020-03-05 07:56:41

If you plan to keep Delphi 7 compatibility, I guess my XE4 is safe then

ab · 2020-03-05 08:45:53

@urhen
About FPC being more tuned sometimes, it is already the case.
Just by the fact that Delphi asm doesn't accept AVX2, whereas FPC has no problem with it... So our AVX2 assembly code is already for FPC only!

@edwinsn
I would like to restrict the official versions. For instance today a XE3 compilation bug was reported, which doesn't exist on XE4 - see https://synopse.info/forum/viewtopic.php?id=5317
So it is not because it works on Delphi 7 and XE4 that it will work on versions in-between! Especially Delphi 2009/2010 where very broken.

Chaa · 2020-03-05 08:48:21

I use Delphi XE5 on Windows and FPC on Linux, so I hope they will be supported at the same level.

As you can see earlier, I am interested in date/time milliseconds resolution.
Now, I am working on some patches for SynSQLite.Utf8SQLDateTime and mORMot.TJSONSerializer.WriteObject.

Maybe, it's time to think about adding ftDateMS to TSQLDBFieldType (datetime vs datetime2 for MS SQL, datetime vs datetime(3) for MySQL). And maybe even about milliseconds in TTimeLog.

ehkhalid · 2020-03-05 09:16:28

+1 for splitting units and versioning.
+1 for non-visual component (even if it's not a priority)
For old compilers, i think we have to consider only compilers that are most used by Mormot users, so maybe open a survey and ask users, and make a deadline (for example maintain delphi 7 for one year ) so programmers can have a delay to migrate their app.

edwinsn · 2020-03-05 10:16:31

@ab,
No problem at all! I can contribute for the XE4 compatibilities

igors233 · 2020-03-05 15:24:46

One of main mORMot strengths is number of supported Delphi versions. For D5 it's OK to remove but I would suggest to make one last stable release with code base as is where all available compilers are supported. Perhaps consider adding critical bug fixes in it (if found).

For other Delphi (XE) versions, It's not necessary to support each version in nightly builds but it would be good to have couple of times a year stable/official release where all >= D7 versions are supported.

macfly · 2020-03-05 17:08:00

mORMot 2.0 = Delphi 10.3 and FCP (with fixes e new features).

mORMot 1.8 = Delphi 7... Delphi 10.3 and FCP (whit fixes only)

ab · 2020-03-05 18:06:11

https://synopse.info/fossil/info/feeea6c40f5fb800
should fix Fossil -> GitHub synchronization problem (rsynch bug in our usecase)

@macfly
This would be easier for me - only two versions to maintain - but we would loose most of the mORMot users, which can't upgrade easily to the latest Delphi revision, for various reasons (mainly the upgrade price)...

Eugene Ilyin · 2020-03-06 08:59:27

Besides D5 (maybe D6) drop, can we drop Kylix support also (due to FPC domination)? Write library for mORMot framework with Kylix support (because mORMot support it) is not fun.
Sermer is perfect (hope that 2.* will exists as much as 1.18 )
Please keep synking with git - this is the easiest way to have own git branches with required framework tuning.
Some whats new section/blog/file will be nice (maybe as git releases with notes) to skip sources analysis for changes for the last couple of months to see what new functions created/updated.
Speed techniques for different aspects of framework: mORMot has 4-8 ways do to the same work, I always have feeling that my code calls/usage are not optimal for my cases. Of couser some functions docs have "good/better/best" hints, but not for all day-by-day calls. Like string manipulations, search, arrays, JSON, TDocVariantData, etc.

Javierus · 2020-03-06 09:06:07

First: The blog topic has fooled some people: yesterday I was told that you were dropping Delphi and keeping only FPC.

1) Compiler versions: whatever you decide will be fine. Myself, just finished migrating from D5 to D2007, and halfway from D2007 to D10.3.3
2) Non-visual components: a must te get more users onboard
3) Spliting units: Bravo! Right now loads of wonderful stuff is lost there
4) Spliting documentation: from mobile devices is very very difficult loading the current page; many times I just can't load it all. There is even a chinese page that uses your documentation page as demonstration for a web client library performance

Please, please, split the project in subprojects that will give both more visibility and more users. Right now I've started to use just your JSON library, but it took with it a load of unrelated stuff. Make it so you have, say, "Core", "JSON", "Mustache" and all the great stuff.

You will have perhaps 5 or 20 subprojects, that will attract developers by themselves. Each repo will get people looking for that specific stuff, and once they are onboard, it's way easier they are interested on the other stuff

I'm probably wrong, but I believe spliting and decoupling your repos will boost very much the mORMot family

Greg0r · 2020-03-06 10:08:11

For all very old Delphi lovers:
Here something for you: https://winworldpc.com/product/delphi/1x

I suggest to you to use 1.0 why so "new" like 2007?
Mindset of all "1.0" lovers is just funny for me.

I'm staying strong that min version should be Tokyo (which is by the was the last edition officially supporting XP)
If you want to go little more compatible option: XE7 as minimum, absolute total min should be XE4.

Summary:
Go with Tokyo(best) or XE7 - that's all.
For absolutelty free - good Lazaurs/FPC is here.
For no/low income - free Embarcadero Community edition. Latest 10.3.3 for free.

Spending valuable time to save "1.0" users - waste of time - and NO its NOT mORMot strength! It's exactly reverse -
this is sensless ballast and perfect stopper of develop(er)/mnet

For those who need very old, mormot 1.x is there - which support should be slowly dropped soon or max end of 2020.

ps. "1.0" - irreverent naming of very old D users.

Last edited by Greg0r (2020-03-06 10:10:48)

ab · 2020-03-06 10:32:01

@Javierus "split the project in subprojects"... in fact I was going into the opposite direction.
A lot of units will always be shared among projects.
And due to that, we have regularly a lot of problems with users having e.g. SynCommons.pas from SynPDF project and mORMot project in their path, and failing to compile.
So my idea would be to remove separate projects, and download and use mORMot as main source. If units are refactored into smaller and well-scoped units, it would be just fine to use only SynPDF or SynMustache and not the REST/ORM/SOA part.

ab · 2020-03-06 10:41:48

I have made a Google Survey to have your insights!

Please check https://forms.gle/Hxa3yT6XQVvVNB3h9

ab · 2020-03-06 11:36:20

Also started a new repository: https://github.com/synopse/mORMot2

macfly · 2020-03-06 12:02:01

If synchronization problems have been resolved, then the fossil can be maintained. It is one more option. This was my vote.

I agree with @Greg0r, Delphi 7 is from 2002. If someone has not migrated to a higher version so far it is because they will not do so in the next few years.

I have a legacy application in delphi 7, and I will continue to use mORMot 1.18 on it.

Frameworks are gaining popularity faster than mORMot and are focused on newer compilers.

The time to cross the road has passed.

@ab,

I know, but you will not lose them because mormot 1.18 will continue to exist (with fixes only).

I use Delphi 7 and I am aware that at some point the third party components will no longer be updated. This happens all the time. IDE itself was a long time ago.

Sorry to go into this subject, because I may be intruding on something that is your subject, but I see many changes / improvements that you introduce, but that generate some incompatibility with version X, so it is corrected and stops working in version Y. I imagine let this be frustrating and take up a lot of time. Sometimes because only one user is using that version of Delphi.

Last edited by macfly (2020-03-06 12:38:48)

Javierus · 2020-03-06 12:54:52

ab wrote:

@Javierus "split the project in subprojects"... in fact I was going into the opposite direction.
A lot of units will always be shared among projects.
And due to that, we have regularly a lot of problems with users having e.g. SynCommons.pas from SynPDF project and mORMot project in their path, and failing to compile.
So my idea would be to remove separate projects, and download and use mORMot as main source. If units are refactored into smaller and well-scoped units, it would be just fine to use only SynPDF or SynMustache and not the REST/ORM/SOA part.

I still advocate for this... But not replicating all the code on each repository; what I suggest (from the ignorance) is having side-by-side repositories, with "Core" repository(es) used by the other repos. It's not uncommon to see a repo that needs another repo from the same author, or even needs Spring4D or whatever else

All in a single repository, even if it's easy to use just a part of it, will scare devs. And not only newbies. (Do we still have newbies in Delphi?)

ab · 2020-03-06 13:38:12

I am preparing the new repository, and start naming things and folders.
Check https://github.com/synopse/mORMot2

We propose to switch to dotted named units, e.g. mormot.core.json.pas - see https://github.com/synopse/mORMot2/tree … its-naming
By design, it using dotted names would void Delphi 7 compatibility. But should work with Delphi 2007, which may still be maintained in mORMot 2: it generates small executables, has inlining, and most of the Delphi 7 code runs on it with no problem, since it was the last pre-UnicodeString Delphi version.

AOG · 2020-03-06 15:24:37

Hi Ab,

I would like to ask you not to include the static binaries into the repo.
Binaries are not handled very well. And will blow-up the whole repo with every commit.

Please use the releases for the sqlite3 binaries. With appropriate naming.
Also, old binary releases are very easily accessible this way.

Thanks.

edwinsn · 2020-03-06 15:55:17

@ab,

I filled and submitted the survey form. The most important thing is: Please keep the current forum, it contains a lot of value-able contents!!!

ab · 2020-03-06 16:06:58

@AOG
Good idea about static content. If we publish releases often (monthly), it wouldn't be a problem to have the .o/.obj files only in the release file. Regular user won't use the daily snapshots, but only upgrade from one release to another - which would provide more testing.
I guess the .dll files should also be distributed with the release.
With current 1.18 with no regular release, the static files were included in GitHub but not in Fossil.

ab · 2020-03-06 17:58:01

Update: sounds like if Delphi 7 does support dotted unit names (at least to the extend we need, i.e. just dots in names)... so we may still support it...

Soon more than 45 answers to the survey!
Thanks a lot! And please continue sharing your thoughts!

George · 2020-03-06 21:20:12

Documentation is already in a markdown-like format (closer to RTF in fact), and maintained within the source code. See https://synopse.info/fossil/finfo?name= … mework.pro

My thoughts was about html documentation.
Currently, md format is primary documentation format, used everywhere.
For example, https://angular.io/guide/architecture
And https://docusaurus.io is just one of many services that can help with that.

urhen · 2020-03-06 21:31:21

ab wrote:

@Javierus "split the project in subprojects"... in fact I was going into the opposite direction.
A lot of units will always be shared among projects.
And due to that, we have regularly a lot of problems with users having e.g. SynCommons.pas from SynPDF project and mORMot project in their path, and failing to compile.
So my idea would be to remove separate projects, and download and use mORMot as main source. If units are refactored into smaller and well-scoped units, it would be just fine to use only SynPDF or SynMustache and not the REST/ORM/SOA part.

Maybe 'split' it into subfolders for easier use and not having 500 files in a single dir. If someone just needs the JSON part, he just takes the JSON folder. If the needs the PDF stuff, take the PDF folder. (Maybe also a core or common folder with global defines etc but should be as small as possible and not like 2mb as the SynCommons.pas now )

EDIT: I think you can also reference other projects in your github project - so you don't need to move everything into one big project. When you do 'git clone' then it gets also the latest version for SynPDF e.g. Might be easier for error reporting if it's only related to JSON and not to the fully mORMot project

Last edited by urhen (2020-03-06 21:42:42)

oz · 2020-03-06 22:40:04

ab wrote:

@Javierus "split the project in subprojects"... in fact I was going into the opposite direction.
A lot of units will always be shared among projects.
And due to that, we have regularly a lot of problems with users having e.g. SynCommons.pas from SynPDF project and mORMot project in their path, and failing to compile.
So my idea would be to remove separate projects, and download and use mORMot as main source. If units are refactored into smaller and well-scoped units, it would be just fine to use only SynPDF or SynMustache and not the REST/ORM/SOA part.

I'm totally with you over here. Splitting into smaller units is a good idea, but don't split into sub-projects. That's worth nothing and only introduces new problems. One project to rule them all ...

About compiler support:
Hmm, well, thats a difficult decision...
Delphi 5 and Kylix support is no longer needed for sure. I think no one is using those compilers in combination with mORMot seriously.
But then things get complicated. I guess there are some users for every other version...
Let's wait for the result of the survey which versions are worth to be supported in mORMot2.
We're using Delphi 10.3 and D7 (only one older project left) over here. But the D7 project has to be merged to 10.3 anyway.
The current mORMot codebase is very stable and mature in general. Only bugfixes in 1.18 version from now on will be perfectly fine.

Maybe it's even worth the big cut to support Delphi 10.3+ and FPC only?
Being able to use current language features in mORMot2 would be nice, wouldn't it?

But that won't work in reality I guess

ab · 2020-03-07 01:41:25

I have written a first version of mormot.core.types.pas in https://github.com/synopse/mORMot2

It could give you a taste of the rewrite I have in mind.
Code seems much easier to follow IMHO.
I put all the asm in separated include files, and made a deep refactoring of conditional uses, to avoid most $ifdef $endif...
And I used the cnpack code formatter to ensure it has a "standard" layout.

Feedback is welcome!

igors233 · 2020-03-07 06:15:49

> And I used the cnpack code formatter to ensure it has a "standard" layout.

Great, much easier to read.

> Feedback is welcome!

Perhaps move functions to different unit and keep this one strictly with type and const declarations. That unit would normally rarely change while functions in new unit could get occasional updates.

AOG · 2020-03-07 07:10:15

Looking very good !!

mpv · 2020-03-07 07:54:40

Mormot2 looks good!
Formatting code using well known automatic tool is a HUGE step forward for a project with many contributors. The only thing to investigate is "cnpack code formatter". May be someone know how to apply the same rules for JEDI code formatter (Ctrl+D) in Lazarus?

In case we now have a new repository may be we can apply such best practice (as used in most well known open source projects):

- rename all ReadMe.md -> README.md (easy to found such file, almost all open source repo I know use such convention)

Keep only things important for developers in sources:
- move license code block from source files into LICENSE.txt (also well known naming convention); keep only short comment about framework and licenses (for example as 3 first line in SynCrtSock.pas)
- move contributors list from source files (and readme) into AUTHORS.md (names inside can be grouped by subsystem or ordered somehow)

Give people a easy way to see what's changes overall (without reading all sources one-by-one):
- move change logs from sources into CHANDELOG.md; use Keep a change log recommendations (this is de-facto standard) for it
Depending of sub-sysytems structure we can have one CHANGELOG in root of the project or one file per subsystem (core/CHANGELOG.md, db/CHANGELOG.md, ....)

- avoid using of spaces and special characters in folder/file names (this is mostly about Samples sub-folder in current repo) - very hard to works with such names from a command line

mpv · 2020-03-07 08:13:25

The github commit diff display is just a joke: it doesn't show more than a few dozen modifications... Whereas fossil diff view has no problem with MB of diffs.
The latest Fossil version includes a basic forum feature, which could be nice to have a single website for all. And self-hosted.Not at Micro$oft's...

Totally agree. We use a gitlab (self-hosted because out company have > 1000 projects) but gitlab.com provide the same functionality:
- code review and merge from WebUI ( diffs can be expanded)
- code editing from WebUI
- Continuous Integration - this is a most important thing (for all my FPC / Javascrit projects tests executed on every commit) @ab - we can provide a gitlab runner (a host for build and run tests) for FPC windows/linux on our infrastructure (for free ofcourse) in case you decide to use gitlab.com (a send you a e-mail with details). For Delphi no because of Delphi license.
- not M$ (gitlab made in Ukraine )
- issues, marge requests, static pages hosting and many-many more.....

For non gitLab hosted git projects we use a JetBrains IDE for merging locally (brilliant tool - one of the best GIT integration I see, far-far ahead of all other tools)

Last edited by mpv (2020-03-07 08:24:09)

ab · 2020-03-07 10:52:14

@mpv
I used CnPack because JEDI/Ctrl+D was not able to recognize the source code because of the $ifdef.
I have added README.md, CONTRIBUTORS.md, CHANGELOG.md and LICENSE.md files, and kept the comments in units as small as possible, as you proposed.

About GitLab integration, do you propose to host the public repository, and continuous integration?
Perhaps that could be a perfect solution!

danielkuettner · 2020-03-07 11:03:22

Although I've comprehension for this activities (1.18->2.x) we have a larger ERP project based on mORMot since 2014 and we love mORMot (and his genius AB) because of:

- stability
- awesome performance
- Interfaced based services/http.sys + TDocVariantData + MongoDB / ZEOS integration which is leading as a package for client/server side projects (IMHO)
- support of older Delphi versions (we use XE5/XE6 and save money)
- we want to change to linux in the future but atm I'm not able to compile the SynSelfTest.dpr (yes I've read the fm, used fpcupdeluxe and i've achieved a lot of knowledge in freebsd/linux since 1997 and I love linux btw but I'm developing software only under windows)

We couldn't spent time in refactoring because our codebase on top of mORMot needs our attention. So I fear losing updateability.

Last edited by danielkuettner (2020-03-07 12:05:20)

mpv · 2020-03-07 12:08:30

About GitLab integration, do you propose to host the public repository, and continuous integration?

GitLab allow to separate hosting and CI (at last self-hosted gitlab does) . So you can migrate a mORMot2 to the gitlab.com - "Free" plane is enough for our needs (hosting FOSS project in the private cloud is a rusks for community - better to use gitlab.com) .
And I provide a gitlab runners in my private cloud (Windows and Linux VM with FPC and Gitab integration software installed) - runners whar available on gitlab do not support FPC as a compiler and installing FPC on every build from scratch is a pain.

I will now do a test project on gitlab.com to test external runners intergation....

mpv · 2020-03-07 12:30:45

Uau! Works like a charm - example of CI for test FPC project is here - https://gitlab.com/pavel.mash/testexter … /124169092
I commit a changes -> gitlab notify my private runner (with FPC already installed) -> runner checkout changes and execute a CI scenario - https://gitlab.com/pavel.mash/testexter … lab-ci.yml
In scenario I compile a test program (on build stage) and run it (on test stage)

P.S.
It's take 22 minutes for me to create a CI for FPC and gitlab

Last edited by mpv (2020-03-07 12:31:50)

mORMot Open Source

#1 2020-03-03 19:10:55

Revision 2.x of the framework

#2 2020-03-03 20:13:09

Re: Revision 2.x of the framework

#3 2020-03-03 20:19:52

Re: Revision 2.x of the framework

#4 2020-03-03 20:20:07

Re: Revision 2.x of the framework

#5 2020-03-03 20:37:56

Re: Revision 2.x of the framework

#6 2020-03-03 20:42:21

Re: Revision 2.x of the framework

#7 2020-03-03 21:05:30

Re: Revision 2.x of the framework

#8 2020-03-03 21:14:07

Re: Revision 2.x of the framework

#9 2020-03-03 21:54:57

Re: Revision 2.x of the framework

#10 2020-03-04 08:40:32

Re: Revision 2.x of the framework

#11 2020-03-04 13:08:29

Re: Revision 2.x of the framework

#12 2020-03-04 13:28:36

Re: Revision 2.x of the framework

#13 2020-03-04 14:50:32

Re: Revision 2.x of the framework

#14 2020-03-04 16:13:12

Re: Revision 2.x of the framework

#15 2020-03-04 16:24:10

Re: Revision 2.x of the framework

#16 2020-03-04 16:29:28

Re: Revision 2.x of the framework

#17 2020-03-04 20:15:18

Re: Revision 2.x of the framework

#18 2020-03-05 07:56:41

Re: Revision 2.x of the framework

#19 2020-03-05 08:45:53

Re: Revision 2.x of the framework

#20 2020-03-05 08:48:21

Re: Revision 2.x of the framework

#21 2020-03-05 09:16:28

Re: Revision 2.x of the framework

#22 2020-03-05 10:16:31

Re: Revision 2.x of the framework

#23 2020-03-05 15:24:46

Re: Revision 2.x of the framework

#24 2020-03-05 17:08:00

Re: Revision 2.x of the framework

#25 2020-03-05 18:06:11

Re: Revision 2.x of the framework

#26 2020-03-06 08:59:27

Re: Revision 2.x of the framework

#27 2020-03-06 09:06:07

Re: Revision 2.x of the framework

#28 2020-03-06 10:08:11

Re: Revision 2.x of the framework

#29 2020-03-06 10:32:01

Re: Revision 2.x of the framework

#30 2020-03-06 10:41:48

Re: Revision 2.x of the framework

#31 2020-03-06 11:36:20

Re: Revision 2.x of the framework

#32 2020-03-06 12:02:01

Re: Revision 2.x of the framework

#33 2020-03-06 12:54:52

Re: Revision 2.x of the framework

#34 2020-03-06 13:38:12

Re: Revision 2.x of the framework

#35 2020-03-06 15:24:37

Re: Revision 2.x of the framework

#36 2020-03-06 15:55:17

Re: Revision 2.x of the framework

#37 2020-03-06 16:06:58

Re: Revision 2.x of the framework

#38 2020-03-06 17:58:01

Re: Revision 2.x of the framework

#39 2020-03-06 21:20:12

Re: Revision 2.x of the framework

#40 2020-03-06 21:31:21