and about DA-Soft.... Divination upon DA-Soft sudden claim is a trend of a week in Delphi-related circles. Let me play with my crystal ball as well.
and about DA-Soft.... Divination upon DA-Soft sudden claim is a trend of a week in Delphi-related circles. Let me play with my crystal ball as well.
Two most important claims that DA-soft made are:
1) DA-Soft cancels all their support for integration with 3rd-party products and claims that 3rd parties would do integration instead.
2) DA-Soft bans any use of FastCode project in their libraries.
How you interpret those claims i not totally clear. For example
1.1) that may be just marketoid fuss to shift responsibilities. "We would not support parts, that you purchased, but please blame someone another, not us"
1.2) that may mean that 3rd-party teams would be FORCED to provide integration if they wanted to be in Delphi market.
1.x) ...maybe more ideas ?
2.1) DA-Soft bans all FLOSS code. But they hardly can do it - client parts for many servers like Firebirdm mySQL, SQLite, PostgreSQL and others are FLOSS and unless they quitting support those, they would have to use FLOSS code anyway.
2.2) DA-Soft ban all native x86/x64 code and going rework their base framework in such a heavy way, that simple conditional compilation would not help. That probably mean more than adding ARM support, i belive native ARM would perfectly fit into low-level optimized x86 code by $IfDef-ing some parts.
2.x) ...maybe more ideas ?
I also want to put few things about DBX.
3.1) initially DBX was made to allow 3-rd parties to participate, plug into DBX frameworks and provide support for databases that B/CG/EMB could not at the moment. However EULA changes in XE2 and XE3 clearly shows hat EMB is seeking ways to kill independent DBX providers market.
3.2) DBX is bases on Microsoft COM infrastructure, which made a lot of sense when Dephi.Net was thought to be next best thing. However it hampers portability. In desktop/server Linux you perhaps could use Mozilla XPCOM library, but that can hardly apply even to Android, less so for Apple. That means most probably in Mobile Studio there was no local DB connectivity, all database work could only be done via network as DataSnap and ClientDataSet.
So now to bring it all together.
DA-Soft obviously are departing from current Delphi compiler (dcc32/dcc64/dccosx) and are going to some virtual machine as their primary target. That may be CIL or JVM (RemObjects Oxygene), LLVM (Delphi next-gen?) or JS (SmartMobile line-up). But it would be some VM-based compiler and if their future releases would still have some compatibility with dcc32 and desktop Delphi - depends only upon our luck.
RemObjects already have their strong DB-access framework. And DA-Soft was told to be founded by ex-RO team. So merging of DA-Soft into RO is least probable.
SmartMobile studio is iteresting but very niche and very risky product, DA-Soft should not put all its bets into it.
There were precedents of Russian companies merging together, but that all was around Firebird/Interbase data servers. Thus server-agnostic product by DA-Soft would not fit in.
So i think that the most probable is the only left outcome: DA-Soft probably goes to be closely affiliated if not owned by Embarcadero. That would make 3rd-parties seek integration and compatibility, just like DA-Soft announced.
DA-Soft and DevArt, offered terrific support for their products in forum. There would be no more support for DA-Soft product. Well, there would probably be Embarcadero support for it, if you can see the difference.
DA-Soft would close the gap in VM-targeted MobileStudio offering and would only formally support native-x86 oriented desktop Delphi/BCB.
All above is just mere speculations and rather pessimistic ones. I'd be glad if someone would provide better and brighter reconstruction.
Two most important claims that DA-soft made are:
1) DA-Soft cancels all their support for integration with 3rd-party products and claims that 3rd parties would do integration instead.
2) DA-Soft bans any use of FastCode project in their libraries.
How you interpret those claims i not totally clear. For example
1.1) that may be just marketoid fuss to shift responsibilities. "We would not support parts, that you purchased, but please blame someone another, not us"
1.2) that may mean that 3rd-party teams would be FORCED to provide integration if they wanted to be in Delphi market.
1.x) ...maybe more ideas ?
2.1) DA-Soft bans all FLOSS code. But they hardly can do it - client parts for many servers like Firebirdm mySQL, SQLite, PostgreSQL and others are FLOSS and unless they quitting support those, they would have to use FLOSS code anyway.
2.2) DA-Soft ban all native x86/x64 code and going rework their base framework in such a heavy way, that simple conditional compilation would not help. That probably mean more than adding ARM support, i belive native ARM would perfectly fit into low-level optimized x86 code by $IfDef-ing some parts.
2.x) ...maybe more ideas ?
I also want to put few things about DBX.
3.1) initially DBX was made to allow 3-rd parties to participate, plug into DBX frameworks and provide support for databases that B/CG/EMB could not at the moment. However EULA changes in XE2 and XE3 clearly shows hat EMB is seeking ways to kill independent DBX providers market.
3.2) DBX is bases on Microsoft COM infrastructure, which made a lot of sense when Dephi.Net was thought to be next best thing. However it hampers portability. In desktop/server Linux you perhaps could use Mozilla XPCOM library, but that can hardly apply even to Android, less so for Apple. That means most probably in Mobile Studio there was no local DB connectivity, all database work could only be done via network as DataSnap and ClientDataSet.
So now to bring it all together.
DA-Soft obviously are departing from current Delphi compiler (dcc32/dcc64/dccosx) and are going to some virtual machine as their primary target. That may be CIL or JVM (RemObjects Oxygene), LLVM (Delphi next-gen?) or JS (SmartMobile line-up). But it would be some VM-based compiler and if their future releases would still have some compatibility with dcc32 and desktop Delphi - depends only upon our luck.
RemObjects already have their strong DB-access framework. And DA-Soft was told to be founded by ex-RO team. So merging of DA-Soft into RO is least probable.
SmartMobile studio is iteresting but very niche and very risky product, DA-Soft should not put all its bets into it.
There were precedents of Russian companies merging together, but that all was around Firebird/Interbase data servers. Thus server-agnostic product by DA-Soft would not fit in.
So i think that the most probable is the only left outcome: DA-Soft probably goes to be closely affiliated if not owned by Embarcadero. That would make 3rd-parties seek integration and compatibility, just like DA-Soft announced.
DA-Soft and DevArt, offered terrific support for their products in forum. There would be no more support for DA-Soft product. Well, there would probably be Embarcadero support for it, if you can see the difference.
DA-Soft would close the gap in VM-targeted MobileStudio offering and would only formally support native-x86 oriented desktop Delphi/BCB.
All above is just mere speculations and rather pessimistic ones. I'd be glad if someone would provide better and brighter reconstruction.
"I'd be glad if someone would provide better and brighter reconstruction."
ReplyDeleteMe too. ;)
Some forum rumors told that Dmitry Arefiev himself worked for RO. Maybe that was a false gossip.
ReplyDeleteHonestly, I'd prefer such speculation to be kept on EMBT, Delphi, Non-tech. It's politics, not development. This kind of speculation is one of the reasons I don't bother with the official forums. But then again, that's just my opinion.
ReplyDeleteDBX is NOT based on COM. That's totally false.
ReplyDeletehttp://web.archive.org/web/20070426050053/http://blogs.codegear.com/steveshaughnessy/archive/2007/02/16/31865.aspx
ReplyDeleteAt least DLL drivers used IUnknown binary convention for mapping
datatypes which was popularized by MS OLE/COM and which hardly applies
to non-x86 CPus that Mobile studio gonna target.
I will repeat: DBX does not use COM. Using IUnknown doesn't mean you are using COM.
ReplyDeleteWell, the Borland blog linked above claimed that DBX at least used COM
ReplyDeletebefore DBX4
And well, Change COM for "COM-popularized IUnknown" the idea remains:
the binary data representation, closely tied to Wintel platform and
not so easilyused on non-x86 CPUs.
Not true -- DBX was designed from the ground up to be platform independent. There's no COM involved.
ReplyDeleteWell, some of the DBX interface classes have a GUID for some reason. AFAIK, the GUIDs are only used for COM interop?
ReplyDeleteNooo, not true at all. GUIDs are used by the Supports call and other places.
ReplyDeleteIt's a persistent but incorrect notion that using interfaces somehow invokes COM. The only way COM gets invoked is when, well, you actually invoke a COM object.
Someone should update the docs, then.
ReplyDeletehttp://docwiki.embarcadero.com/RADStudio/XE3/en/Object_Interfaces
Under Interface Identification and GUIDs
"Note: GUIDs are only used for COM interoperability."
Yep, someone should indeed. ;-)
ReplyDeleteHow i see the picture.
ReplyDelete1.There are a lot of RPC protocols, starting with SunRPC. If passing self as explicit parameter a la HWND is inconvenience, there still are a lot of OO RPC like ORBit/VisiBroker/etc, xml-rpc, json-rpc and god knows what else. DBX chosen IUnknown. Why? 2.Because Microsoft by means of COM/OLE popularized it enough to be 1sr class citizen in most languages, thus DBX drivers would be developable by any dbms team in their toolchain. I can't no for sure if there could be plans to promote dbx outside delphi, but i think potential converging witj bdp.net was considered at least.
3. However IUnknown only is mainstream on wintel. Step aside and at best you'd have to use some wrappers and bridges to 3rd party library like mozilla xpcom on non-Win x86 . And there hardly be IUnkown binary types mapping standard on mips, arm,powerrpc, etc. And it is yet worse for VMs.
4. So when we think about Mobile Studio, putting IUnknown at dbx core made it essentially not x-platform, at least in sense of 3rd party support.
IUnknown is just a name -- it could be called IAppleCart.
ReplyDeleteRepeat: DBX is not tied to a platform.