GetIt is the new XE8 package manager for RAD Studio. Information about how to submit your libraries to GetIt has just been made available by Embarcadero. The idea behind GetIt is really to make is easier and faster to discover, install, and keep updated some of the best open source libraries for Delphi and C++Builder.
When you look at the approval conditions, it sounds like if mORMot would not find its way in this package manager:
Replacing key capabilities that are part of the core platforms definitions such as Client/Server FireDAC pack or the DataSnap/EMS Enterprise middleware, would be less likely to be accepted.
This is the discussion thread for http://blog.synopse.info/post/GetItIfItWontHurtOurSells
In their terms, "The different SKUs are meant for different types of developers, and multi-tier capabilities with strong client/server RDBMS integration REQUIRE an Enterprise edition license." reminds me clearly the XE3 times.
At least this requirement is not part of the licence terms. Their article is misleading.
For me it is time to rethink the investment in delphi. With all the hassels and the "milkink" of the customers i dont believe animore in EMB as a partner. They want opensource projects for better selling the product,
not to make the product better.
By the way: next time you are in Strassbourg we should take a beer!
Last edited by Fritz (2015-06-06 15:42:22)
@Fritz Good idea for the beer! I would be in Strasbourg the 1st of July.
Is it true that "strong client/server RDBMS integration require an Enterprise edition" ?
We will bias acceptance toward GetIt libraries that respect the spirit of our licensing and editions, not just use the letter of the license and the technical boundaries. If you are unsure about your submission please check with us first.
http://community.embarcadero.com/index. … s-to-getit
What the fox is this "spirit of our licensing and editions"?
Why is it not part of the official license terms?
Where does this assumption comes from?
Would the licensing conditions change in the close future, as with the XE3 "episode"?
Would the Marco interpretation become the new rule?
Story repeats itself.
I just wanted to ensure that the licensing terms would not change in that direction.
I - as many Delphi users - would not let this GetIt "spirit" become the new rule.
I think they should give away the professional version of Delphi to students and hobbyists but on the understanding it's only used for non-commercial uses. I'm sure 99% of people would upgrade if they started making money from it. PKzip, for example, was shareware but was apparently profitable to it's company.
My first version of Delphi was version 3 which I got on the cover of a UK computer mag. I just paid £20 for the printed docs. Then bought Delphi 5 as a shrink wrapped box off eBay and upgraded it a couple of times. If I'd had to pay the full price I wouldn't have used it.
I am mainly using Delphi because mORMot exists. I really like Object Pascal and Delphi but mORMot gives me the power do develop Enterprise grade Applications. Plus: since it's open source you can dig into the source if you ever have a real problem AND I have never experienced such a responsive forum for any other framework
Last edited by martin.suer (2015-06-09 19:37:12)
I find it a bit strange that all just start by having a negative attitude. They clearly state that you are welcome to contact them with questions and/or just try to submit. So I suggest you ask them if mORMot would qualify and if the answer is No then I am sure that I and many others will gladly join in complaining.
If on the other hand the answer is Yes, we don't have to waste energy complaining up front.
As to the "spirit of licensing and editions" I think it is fairly obvious what they are referring to. They don't want to put anything on GetIt that would cost them any significant amount of sales. It has nothing to do with your or mine Delphi end-user license terms as far as I can see.
I submitted mORMot to getit. We will see the answer.
But I still do not agree with their position, in respect to other packages managers, in c#, perl, python or ruby.
They have a very close spirit.
As with my negative reaction: "once bitten, twice shy"...
Latest news on it.
A few weeks ago (end of june), I got a mail from Marco.
Sorry for the delay. We can accept this SynPdf submission and the SynGDIPlus
submission as well, although I’m personally a bit worried about a
partnership with someone who tends to take excuses to be negative with our
product, like your recent post about compiler optimization based on one
single codegen scenario.
Regarding the SynCrypto, this is a great library, but we have legal
concerns, as in general as a US company hosting encryption code can be
done only following very specific rules and/or asking for government
authorization. We do it for the limited code we ship, but it becomes
tricky for an external submission.
Regarding mORMot, it is currently on hold as it is not in line with GetIt
policies. We’ve asked internally to double check this, but we really don’t
want to have customers using GetIt adding to Delphi Professional
capabilities that are in the “Enterprise” space. I know what you have
written about this, but this has always been the case in the product since
day one. Even if our license can be bypassed in a "formally legal" way, it
does mean we are happy about it and will incentivate it. Delphi Pro is a
product for those who don’t need client/server database connectivity.
So you got the info.
This answer does make sense, from the Embarcadero point of view.
I do not want to argue about it.
In fact, my blog article was realistic.
I did not want to be negative, nor cynic.
But in France we use to say "Chat échaudé craint l'eau froide" - "once burned, twice shy"...
And... I was pretty right when I wrote that "the main ORM/SOA/REST/MVC/StubMock features would certainly be rejected".
Eventually, it has been the case.
Therefore no offense.
BTW, SynPdf is not part of GetIt yet. Even if it is a very known and widely used library (probably the best Open Source PDF library for Delphi).
Perhaps, since SynCrypto is used within SynPdf (for PDF encryption - which is a nice feature), they were not able to add it.
So it was even worse than I expected.
But the few current GetIt components are great, especially OmniThreadLibrary and ICS.
The Delphinus PackageManager is a tempting alternative.
See http://blog.synopse.info/post/2015/08/2 … ageManager
Still in preview state, but some nice ideas, like the fact that it retrieve its information directly from GitHub search API.
Next Delphi (which won't be named XE9, from Marco words on Google+ AFAIR) would feature MongoDB access via FireDAC.
See http://community.embarcadero.com/write- … or-mongodb
(you may be pretty lucky if the page does load, BTW).
On Google+ - see https://plus.google.com/+MarcoCantu/posts/d7TJDTSZV4Q - I answered to a Edwin Yip question about mORMot MongoDB abilities.
FireDAC MongoDB would need to use a dedicated query construction for MongoDB, incompatible with SQL. So you can't switch from SQL to NoSQL directly, but rewrite all your requests for MongoDB. And it suffers from the "flat" RDBMS approach of the TDataSet: difficult to work with nested documents, from the RAD approach. I'm curious how they manage to do it. IMHO using MongoDB like a RDBMS is pointless.
Our ORM, on contrary, is able to convert the WHERE clause of its data retrieval from SQL like syntax to MongoDB. So you can switch from a SQL to a NoSQL backend in a single line of code. See e.g. https://github.com/synopse/mORMot/tree/ … C%20Server
And, on the other hand, we integrate also document-like storage in SQL databases.
See http://blog.synopse.info/post/2015/08/23/SQLandNoSQL No problem storing complex documents within MongoDB, and handle them in code.
About performance, mORMot interfaces directly its JSON structures to MongoDB BSON. We achieved amazing speed in production. As SQL backend of our ORM, FireDAC was slower than our direct classes. Maybe someone would do a benchmark.
But both approaches are fine, and in fact diverse. FireDAC is RAD-centric, whereas mORMot is clearly REST/nTier/SOA/ORM from the ground up. With FireDAC, you use your mouse and components, whereas with mORMot you write code in services, and split the logic from the UI (up to a Domain Driven Design architecture).
One of my points was wrong.
But Marco over-reacted:
As you say at the end, mORMot and FireDAC have a different approach and focus on different problems. But it was on "your side" that the comparison was introduced.
Having said this I hate this attitude of criticizing a solution before knowing it. The previous message has a lot of FUD about FireDAC MongoDB support. TDataSet is richer than you depict it, and in fact the image in the article even shows a DBGrid connected to a TDataSet with abstract data types and nested tables. Not saying it covers all scenarios, it does not, but your flat criticism is incorrect. And so are the comments about JSON and BSON processing, direct access to MongoDB features and more.
I have no issue when you explain the virtues of your solution (which has some great advantages but also limitations, as any solution), but criticizing what Embarcadero does before knowing the technical details with the attitude "just because it comes from them it cannot be good" is rather annoying.
I'm honnestly feeling it pretty unfair.
Here is my answer:
Blog page is back.
AFAIR I did not start the comparison, but asked explicitly for more information.
AFAIK I wrote "FireDAC MongoDB would need to use a dedicated query construction for MongoDB, incompatible with SQL" is not FUD. It is a fact, shown even by the blog screenshots. You can not switch from one DB to another easily. It is a fact, from the architectural/design point of view: you need an ORM/ODM (or something similar) to abstract the storage layer.
I wrote I was "curious" about how NoSQL concepts were translated to RAD. I'm still not convinced that nested tables with fixed column names do match the "Aggregate SchemaLess" main benefit of NoSQL.This is RDBMS master/detail in disguise.
But I was not right when I wrote that MongoDB was "somewhat restrained to the TDataSet". Like any FireDAC units, you can have direct low-level access to the driver. Even if I wonder which percentage of users do talk directly to the FireDAC.Phys.*.pas units. So it was a "somewhat" practical "restriction".
I edited my post, too much quickly written. I feel sorry if it sounded like FUD. I was wrong in part of my comment. I corrected it. I even thank you for your feedback, even if you answered with "hate" attitude - impugning motives is never helpful. What do you fear?
I never wrote that anything new from Embarcdero "cannot be good". On the contrary, FireDAC is a nice part of Delphi. I wrote that its "approach was fine". We have support for it in mORMot, with no negative terms about it, on the contrary - see http://synopse.info/files/html/Synopse% … #TITLE_178 - we even support some of its features (like array binding).
Like with the old Greek language style, the main point of my post was its final paragraph.
I emphasized in bold/strong my thought.
All this is pretty unfair.
I'm committed to mORMot, sometimes over-enthusiastic.
But without passion, this Open Source project would not be what it is.
Our framework is an opportunity to Delphi or Embarcadero, not a competitor.
IMHO most mORMot users do still use Delphi because of mORMot, otherwise they would have switched to Java or C#.
We like Delphi, as a language and a platform. We leverage decades of (object) pascal practice.
Certainly Marco did "hate" those posts:
http://blog.synopse.info/post/2012/08/2 … -PRO-users
http://blog.synopse.info/post/2013/05/1 … sapointing
http://blog.synopse.info/post/2015/05/0 … ot,-do-you
http://blog.synopse.info/post/2015/06/2 … han-Delphi
IMHO those posts should not be "hated".
They should be taken for what they are: opinions and feedbacks of a long time Delphi user.
Hearing from customers is part of the business, right?
I sometimes react, because I like Delphi, and want it to be always better.
And I know I'm not the only one.
Constructive criticism is indicated. Some of their ideas are sick. I think we need to create our own path, and that path is related to FPC and Lazarus.
I have plans to release full free edition of FreeSparta with mORMot ^^ and with patched compiler (eg. by -> http://svn.freepascal.org/cgi-bin/viewv … rfacertti/ to perform Linux servers out of box).
Great software is about passion, which you have on your open source projects! And I'm really glad to see the progress you have made to support FPC/Lazarus in the past years for mORMot!
Delphi XE4 Professional. Windows 7 64bit.
Please have a look at
http://lists.freepascal.org/pipermail/f … 35891.html
The branch is not yet fully working (some files are missing).
Some RTTI return values have also changed, but luckily do not influence the RTTI part of mORMot !
Looking forward to your work !
Please have a look at
http://lists.freepascal.org/pipermail/f … 35891.html
Looking forward to your work !
Thanks, I observe this subject. New FreeSparta version will take some time.
Last edited by hnb (2015-09-02 08:00:57)
My company did pay for Delphi latest licences....
Unusable for Win64...
http://blog.synopse.info/post/2015/10/0 … ble-target
Edit/Update: Issue fixed!
Allen Bauer recognized that "It was an uninitialized memory allocation" in the QC, and that he is pushing to include the fix into the upcoming Seattle 10 Update 1.
Nice seeing such a quick reaction. Delphi is not dead, even if Embarcadero was just acquired!