[Gdal-dev] RFC 9: ATL Based COM Interface

[Ivan Lucena]

Hi Frank,

>   1) Where will all this source live?  Perhaps in gdal/com?

Tha is how it looks like:

gdal/com <-------------- VC Solution goes here
gdal/com/GDAL <--------- Project file and code goes here
gdal/com/samples <------ Samples that can be use for testing
gdal/com/doc <---------- DOX, html stuff

>
>   2) You indicate the build mechanism will be separate from the regular
>      gdal builds.  Can you explain a bit more about this?  Will the build
>      be based on a visual studio project file instead of makefiles?

The Visual Studio project just need to know where to find gdal_i.lib and the include folders alg and gcore. 

I can write a makefile for that too if you want.

During debugging, the application must find gdal13.dll in the system path.

So, as you can see, the development process is really independent.

>
>   3) What build environments will be supported? Only visual studio?  If so,
>      what versions?

The current implementation is compatible with Visual Studio 2005. I am not sure about other version. I guess that it could also be compiled in 2003. The project is pretty easy to recreate anyway. It doesn’t have a lot of sub-folders, flags and options settings like a big project as the GDAL VS solution.

>
>   4) What timeline and GDAL verison are you looking to incorporate into?
>      Presumably this will go into the development branch (aka 1.5.0-dev)
>      after the 1.4.0 release?

Yes, I believe that it is wise. Once we have this think rolling it will take the cycle of the
next GDAL release to get in to a stable version. I mean GDAL 1.4.x or 1.5.0.

>
>   5) What kind of documentation are you planning to provide for users?

As the RFC says I am planning to keep documentation compatibility with the GDAL C++ API. I will use the “/see” DOxygen tag to point to the original documentation as much as I can. 

>
>   6) How complete a coverage are you planning?  Pretty much everything
>      handled by the swig wrappers?  Only GDAL?  Only the pieces you find
>      you need?

I am planning to cover all the raster support first. I think that the experience is going to make the OGR Interface much easier even tough it is much a bigger job.

> My understanding is that the C# bindings are accessable from any .net 
> language.

I believe that it is true.

> So it seems that the COM interfaces will mainly be of interest to Delphi
> developers - is that right?  I must confess to being a little confused by
> changes in Microsoft object technology, but my understanding was that the
> .net approach to object provision is now preferred to COM objects.

I guess that you right in parts. Delphi will be today the main beneficiary, but you can count VB, ASP or any other COM's friend programming/scripting language on that group too.

>
> Generally speaking I am supportive of inclusion of COM support but I would
> like to see another pass on the RFC to clarify the above points.  I'd also
> stress that the current project direction is still to prefer the c# bindings
> as our ".net solution" - I'd appreciate comment on whether that makes sense.
> Also, does Delphi really have no convenient way of calling .net services?
> It seems like an obvious step for Borland to take.

Let me explain the Delphi problem: There is two Delphi now. The old and traditional (Delphi Win32 or Kilix for Linux) supported by Borland and by some freeware products; and there is a new one called Delphi.Net that is supported only by Borland Studio 2006.

By the way, those product names and company names are changing as we speech.

The programming language syntaxes are similar but not identical so, You pretty much need to write applications to move to Delphi.Net.

So, the answer to you question is No, Delphi can not call .Net jut like VB6 or VC6 C++ can't.

So, I agree with you. I should rewrite the RFC-9 to something like a "COM solution to GDAL" and remove the .Net samples. If you agree.

Best regards,

Ivan