random ramblings on Delphi, programming, Delphi programming, and all the rest
As the Roberto’s blog is not yet included in the DelphiFeeds concetrator, I’d like to bring to your attention his very interesting post: DataSnap analysis based on Speed & Stability tests.
EMB should no longer waste their time developing components where they are not the number one. They should focus on the IDE and compiler. ASAP!!!
If everybody would follow those principles, there wouldn't be much choice to pick from on this world.I do, however, think that Embarcadero should bring in quality programmer that would make Delphi codebase solid once again.
Since they have to less resources, they should just focus on the more important thinks (IDE & compiler), where 3rd party vendors can't help.When you encounter a bug in EMB components, you just can but it into QC and pray that at any time this bug get fixed, if ever. Where other companies are more flexible and are faster providing fixes.
Datasnap is classic example of Borland "non finito". Start with a minimal, barely working implementation of a feature, add something later but never finish and polish the it. Then switch to another feature (Linux, CLX, VCL.NET, MacOS, iOS, Firemonkey) and start again.This test is very interesting because it's telling you that the money spent on the Enterprise SKU are actually thrown away. Datasnap should have been a strong selling point to buy the higher SKU (not only the four more dbx driver you get), but actually it looks it is not.Instead of thinking how to modify licenses about what you can do with the Pro SKU, they should really start to hire good - very good - developers to deliver a product on par with its price. I really hope they're oursourcing development to hire them, non only to get cheaper ones on board, because noone is happy to pay a lot to get half backed libraries - moreover with no support as the article points out - no callbacks, no "we understand, we'll deliver a fix soon".
I fully agree with you on all points.
Give it a thread pool. Before starting the server in the .dpr code:LServer.Scheduler := TIdSchedulerOfThreadPool.Create(LServer);This is XE2, I don't have XE3 yet, but it's probably the same.
You should probably post this on the Roberto's blog.
I fully agree with you on all points. 
I totally agree with LDS.Nice that EMB like to put money and effort in developing a product where they have a much lesser interest in having it documentet. I have made one implementation using DataSnap but had to google alot (and in that skipping the old articles of the previous implementation of DataSnap) and read alot of the source code.Sure there are some documentation (like Dr.Bob) but they take you only as far as doint a "Hello, world" implementation. Usually I am after a bit more solid application...
But is DataSnap quicker and easier to work with? Tweeking is available and would be done on a per deployment basis. So, for me I want to be able to build apps quickly visually. Then I can lock a tech in a closet and they can bang their head against the wall until they make it fast enough.
Yes, "premature optimization" is evil. But technicians only can work on the surface (environment and configuration), core architecture of DataSnap defines the limits for optimizations. Maybe app development is easier, but customers will not happy if they need to operate a lot more server boxes than for a WCF or Java based solution. I welcome the load tests and performance comparisons for DataSnap and other REST frameworks.
Webservices are very common nowadays and I welcome a set of components to implement that, especially when this helps provide a common implementation regardless if I write it in C++, Delphi or Firemonkey (both Desktop & Mobile).
After porting to FMX, TMS Cloud Pack can be a good cross-platform solution!) Now it is VCL solution for some cloud-based services.