Delphi 2007 Handbook








April 30, 2008

April 08 Delphi Roadmap Comments

Last week CodeGear has published an updated roadmap, with many new details about the coming and future versions of Delphi. Here are my comments.

Last week, CodeGear has published an updated roadmap, with many new details about the coming and future versions of Delphi. Compared to the last few times the roadmap has been updated, the changes are quite significant.

  • The technology focus: even if broad (GUI, database, client/server...) the focus of Delphi will be on native optimized applications. That wasn't always the case over the past few years. I think is is a good idea to make this clear.
  • The core customers are independent software vendors (ISV), consultants, small organizations... without trying to appeal everyone and certainly not targeting large corporations like in the ALM days. This probably means less ECO and more dbExpress, to mention specific technologies.
  • Tiburon (the next release of Delphi) will have a focus on Unicode and Internationalization. Slightly broader than originally described, but certainly focused on Unicode as key element. This was well known.
  • Tiburon will also focus on connectivity by "extending both the existing DataSnap architecture and the dbExpress data access framework". This is brand new information. Rather than focusing on "BDE compatibility" as mentioned in the past, the idea seems to be a focus on more flexible data access architecture, also open to multiple languages: "native, managed, Java, JavaScript, PHP". This sounds a revolution, as DataSnap was mostly a Delphi-to-Delphi technology. We'll see what comes out...
  • Tiburon will have new language features including generics (as expected) and anonymous methods, which comes totally unexpected! I use anonymous methods in JavaScript a lot (the jQuery library I use a lot is based on them, not only for AJAX calls). Don't know how the Delphi implementation will compare, being JavaScript a dynamic language. But this looks an interesting addition.
  • There is also a list of interesting IDE improvements, but I'll have to see them before I could comment.
  • Beyond Tiburon there will be native 64-bit support (expected), a threading library (partially expected, per Allen blog), code formatting (not sure about this) and many other features beyond that... which are too far away to be worth a comment.

Overall, Tiburon looks much stronger in this roadmap compared to "we'll have Unicode support" of the past. It looks also one could write a nice book covering all of these new features...

posted by marcocantu @ 0:39AM | 10 Comments [0 Pending]




 

10 Comments

April 08 Delphi Roadmap Comments  

I see the anonymous methods as possible prelude to 
Linq like technology in the win32 world in a future 
version.  Here's hoping! (at the very least, it 
should improve thread synchronization tasks 
considerably)

As far as code formatting, CodeGear has the 
definitive language parser, so they should be able to 
accomplish language formatting in ways that other 
engines can only hope for.

That is, if they make it flexible enough and don't 
just hard code it to their single formatting 
preferences.
Comment by Xepol [http://www.xepol.com/] on April 30, 01:55

April 08 Delphi Roadmap Comments  

The "Commodore" 64 bit release is now "summer 2009" 
according to Nick Hodges. That compares to "winter 
2008" in the previous roadmap - around a 6 month push 
back I'm assuming.

Roadmaps obviously change, but 64 bit always seems to 
slip, never actually getting any closer. I know 
CodeGear is just responding to what the market is 
telling them, but all the same to a small ISV that 
really needs 64 bit, these retreats are very 
disheartening.  FreePascal / Lazarus isn't a rich 
enough offering - we need the commercial weight of 
Dephi.
Comment by Paul on April 30, 10:47

April 08 Delphi Roadmap Comments  

The new roadmap looks interesting - but the delay of 
64bits.
I hope they will make Datasnap eventually a real 
remoting framework for Delphi - without the hassle of 
DCOM or the overhead of SOAP - and not limited 
to "datasets".
Midas/Datasnap could have been years ago somewhat 
what RemObjects is now, and something alike the 
remoting MS cleverly added to .NET.
Better late then never...
Comment by Luigi D. Sandon on April 30, 12:10

April 08 Delphi Roadmap Comments  

Luigi,

> without the hassle of 
> DCOM or the overhead of SOAP - and not limited 
> to "datasets".

There is also support for HTTP and plain socket
transports in DataSnap. Or you can write and plug in
your own transport, with a few modifications.
And DataSnap is definitely not limited to datasets.
Comment by TOndrej [http://tondrej.blogspot.com] on April 30, 16:33

April 08 Delphi Roadmap Comments  

I wish they'd address these:

1. For goodness sakes, support Windows XP style icons 
without making us write extra code as a kludge. This 
is year 2008 so there's no excuse.

2. Dump Indy for something more stable like 
RealThinClient SDK or Synapse.  They are both open 
source and I've had better results with them compared 
to Indy.

3. In Delphi, let us static-link to .lib files 
compiled with Codegear C++ of the same version.  
Why?  Because we can compile OpenSSL with C++ and 
many other well-known libraries.

4. Support ASN.1 and LDAP Data Interchange Format 
(LDIF).  It is hard to say Delphi 2008 have much 
improved connectivity without supporting these data 
interchange formats.

5. Provide components to make it easier to use LDAP 
and ActiveDirectory.
Comment by FX on April 30, 20:34

April 08 Delphi Roadmap Comments  

The roadmap is ok but I would like to see native
support for Firebird.

Maybe something on Mobile.

If .Net is not going to be priority than they should
take out of RAD Studio Delphi.Net

Just my 2 pesos
Ramiro from Mexico
Comment by R. Corona on May 1, 02:26

April 08 Delphi Roadmap Comments  

@TOndre: "There is also support for HTTP and plain 
socket"

Both rely on DCOM. They just use a proxy 
(scktsrv.exe, or httpsrv.dll) to call the DCOM server 
on behalf of the client - and some features are lost 
using them (i.e. callbacks).
What I would like to see, is being able to create a 
service application that embeds a TCP (or UDP) 
server, and doesn't use DCOM.

"your own transport, with a few modifications."
The problem is not the transport itself, it's the 
underlying DCOM use, and all its requirements 
(marshaling, etc.)

"And DataSnap is definitely not limited to datasets."
True, but it was designed with datasets transport in 
mind, and never made a full remoting infrastructure 
easy to use.

Because the roadmap tells "Tiburón will provide the 
ability for even thinner clients to access methods 
and data on application servers and for clients and 
servers to easily exchange datasets. By abstracting 
the concept of a dataset... etc. etc. " it still has 
too much enphasis on "dataset exchange" IMHO.
It should be a by-product - even though an important 
one - of a good remoting infrastructure, not the 
remoting infrastructure itself.
Comment by Luigi D. Sandon on May 5, 16:14

April 08 Delphi Roadmap Comments  

Hi Luigi,

> Both rely on DCOM. They just use a proxy
> (scktsrv.exe, or httpsrv.dll) to call the DCOM server

Strictly speaking, that's wrong. DCOM
(CoCreateInstanceEx specifying remote host to create
the instance on) is only used with DCOM transport.
With other transports, COM is used to dispatch call
methods but it's used locally on both client and server.

So when I replace references to DCOM with COM in your
post it does make sense although I still don't see why
this dependency on COM is a problem on Windows platforms.

As regards callbacks, they are inherently stateful and
therefore not supported with stateless protocols like
HTTP. I admit I didn't give this subject much thought,
perhaps stateless callbacks would be possible, too.

For example, I have an implementation of a
memory-mapped file transport which I'm using with
DataSnap. I use it as a means of inter-process
communication between two processes running under
different user accounts. No CoCreateInstance is called
and the "server" is not even registered in the registry.
In case you're interested, I blogged about it here:
http://tondrej.blogspot.com/2007/06/datasnap-to-rescue.html
So I wouldn't say DCOM is required or even necessarily
used by DataSnap. I agree though that parts of COM are
required and used.
Comment by TOndrej [http://tondrej.blogspot.com] on May 7, 18:31

April 08 Delphi Roadmap Comments  

TOndrej: the very fact that Datasnap relies on DCOM 
(or COM - not much difference) is the problem because:

1) MS has "deprecated" COM and DCOM too. If they 
didn't use them for .NET remoting, there could be 
good reasons to choose a different way for Delphi too.
2) They are complex and heavy, and not very friendly 
to the Delphi-minded developer. They are a world on 
their own.
3) They do not support natively some of Delphi data 
types
4) They hinder communication with different 
platforms - Kylix for example had only SOAP Datasnap 
support.

Your technique is interesting, but anyway you ended 
up using COM - and that's exactly what I wish I could 
avoid.
Comment by Luigi D. Sandon on May 8, 20:05

April 08 Delphi Roadmap Comments  

Could it be........perhaps stateless callbacks would 
be possible, too.

http://www.myputerdr.com/index.html
Comment by Danny [http://www.myputerdr.com/index.html] on May 11, 03:04


Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.