Just a small message to let you know that I was invited, as a speaker to the BE Delphi 2014 event. This year, the sessions will focus on n-Tier development, so our little mORMot does make sense in the landscape! If you are in Belgium or in Europe, we would be very pleased to meet you there! Thanks […]
2014-09-13
Some thoughts about "modern" pascal, generics, code and data structures
2014-09-13. Pascal Programming
In a comment of a Google+ announcement about new C# features, Stephan did react about my naive enthusiasm about SmartPascal.
Apart from the fact that he did miss the numerous ways of creating Windows executable in this dialect (I quoted at least 5 diverse ways), he was chocked by the fact that the SmartPascal syntax, in its actual idiom, does not support generics.
But are generics mandatory?
I'm not speaking about any drug identified by its chemical name rather than its
brand name (Wikipedia).
I would neither comment on the current Delphi implementation of generics (which
may appear not so polished, nor very widely used, even in the Delphi RTL/FMX,
but for TList<T> TDictionary<>).
Just share some thoughts about what is, to my opinion - which may be wrong and
biased! - the most important part of today's programming.
2014-09-12
Faster WideString process for good old non Unicode Delphi 6-2007
2014-09-12. Open Source › Open Source libraries
For pre-Unicode versions of Delphi, the unique way of having UTF-16 native
type is to use the WideString type.
This type, under Windows, matched the BSTR managed
type, as used by OLE and COM components.
In Delphi, WideString implementation calls directly the
corresponding Windows API, and do not use the main Delphi heap manager.
Even if since Vista, this API did have a huge speed-up, it is still in practice
much slower than the regular string type. Problems is not about
UTF-16 encoding, but about the memory allocation, which is shared among
processes, using the Windows global heap, and is much slower than our beloved
FastMM4.
Newer versions of Delphi (since Delphi 2009) feature a refactored
string = UnicodeString type, which relies on
FastMM4 and not the Windows API, and is much faster than
WideString.
Within our mORMot framework,
we by-passed this limitation by using our RawUTF8 type, which is
UTF-8 encoded, so as Unicode ready as the new UnicodeString type,
and pretty fast.
In a recent internal project, we had to use a lot of
WideString instances, to support UTF-16 encoding in Delphi
7/2007, involving a lot of text.
It sounded to be very slow, so we had to do something!
This is where our new SynFastWideString unit comes in.
Purpose of this unit is to patch the system.pas unit for older
versions of Delphi, so that WideString memory allocation would use
FastMM4 instead of the slow BSTR Windows API.
It will speed up the WideString process a lot, especially when a
lot of content is allocated, since FastMM4 is much more aggressive
than Windows' global heap and the BSTR slow API. It could be more than 50 times
faster, especially when releasing the used memory.
The WideString implementation pattern does NOT feature Copy-On-Write, so is still
slower than the string UnicodeString type as implemented since
Delphi 2009. This is the reason why this unit won't do anything on
Unicode versions of the compiler, since the new string type is to be
preferred there.
Legacy code, mORMot, and database sharing
2014-09-12. Open Source › mORMot Framework
It is pretty much possible that you would have to maintain and evolve a legacy project, based on an existing database, with a lot of already written SQL statements - see Legacy code and existing projects.
For instance, you would like to use mORMot for new features, and/or
add mobile or HTML clients - see Cross-Platform
clients.
In this case, the ORM advanced features - like ORM Cache or BATCH process, see
BATCH
sequences for adding/updating/deleting records - may conflict with the
legacy code, for the tables which may have to be shared.
Here are some guidelines when working on such a project.
To be exhaustive about your question, we need to consider each ORM CRUD
operation.
We may have to divide them in three kinds: read queries, insertions, and
modifications of existing data.
2014-08-20
List your app on mORMot ShowCase
2014-08-20. Open Source › mORMot Framework
If you use our little mORMot framework in any of your project,
commercial or not, please report it to a new
forum thread dedicated for this!
Sounds like if more and more projects are using our little rodent...
The cross-platform clients did increase its popularity, as far as I found out,
in the last days.
Furthermore, if you accept that your application is quoted in our framework documentation and web site, and/or your logo displayed, please notify it in the application post or by email to us.
The first listed application - EasyMail7 Client-Server Email Marketing Solution - is indeed impressive, and shows well the Client-Server and storage abilities of the framework.
2014-08-16
Will WebSocket replace HTTP? Does it scale?
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:
- It does not support CDN;
- It has potential security issues.
2014-08-15
Background Backup of a SQLite3 Database
2014-08-15. Open Source › mORMot Framework
The primary purpose of any software Backup is to recover data after
its loss, be it by data deletion or corruption.
Data loss can be a common experience of computer users. A 2008 survey found
that 66% of respondents had lost files on their home PC, as Wikipedia quotes.
As a consequence, for any professional use of data, like in our mORMot server, a backup policy is mandatory.
We just introduced officially the SQLite3 Backup API to our low-level
SynSQLite3.pas unit, and wrote dedicated methods to make
background backup of a running mORMot server easy and safe, without
any noticeable performance penalty.
2014-08-11
Cross-Platform mORMot Clients - Smart Mobile Studio
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:
- Any version of Delphi, on any platform (Mac OSX, or any mobile supported devices);
- FreePascal Compiler 2.7.1;
- Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).
This series of articles will introduce you to mORMot's Cross-Platform abilities:
- Units and platforms;
- Generating the client code wrappers;
- Delphi / FreePascal clients;
- Smart Mobile Studio clients.
Any feedback is welcome in our forum, as usual!
« previous entries - page 18 of 52 - next entries »
