case for open lang on win32 - fill in the table

[Bill Tutt]

> From: Mark Hammond [mailto:MHammond at skippinet.com.au]
> 
> 
> nielsenjf at my-deja.com wrote in message 
> <7r3fhd$oqb$1 at nnrp1.deja.com>...
> 
> >> IDispatch plus about 100 extra interfaces.  We can not use raw
> >interfaces if
> >> there is no C++ support, but many useful interfaces 
> already have that
> >> support (and it is trivial to add new ones).  From a 
> marketting POV,
> >this
> >> should definately read "yes" :-)
> >
> >When you say C++ support, I assume you mean there is code 
> written than
> >allows vtable access for python for some interfaces?
> 
> Exactly.  Although we do have tools that generate the C++ 
> code given the IDL
> file (actually, the .h generated from the .idl).  SWIG also 
> comes to our
> rescue too.  Also PythonCOM supports "plug-ins" - there is no 
> need for this
> C++ support to live in the core COM implementation.
> 
> >Is there c++ support for ADSI or MTS or OLEDB (which look to 
> be the big
> >things for windows 2000)? Or can we only access it via 
> Idispatch(I know
> >perl can do some stuff w/ADSI via Idispatch).
> 
> AFAIK, all of these are supported by IDispatch.  Eg, MTS and 
> OLEDB are all
> fine from Python.  I dont know about ADSI, but if Perl can use it via
> IDispatch I bet we can too.  However, it will definately be 
> true that if
> there are shortcomings there, they will be addressed.
> 

Python can handle any IDispatch interface for MTS. OLE DB is strictly all
non-IDispatch based, and if you went to the work of writing the necessary
C++ code for Python, it'd support those too. 

> >OLDEDB access would be cool since ADO is so slow.
> >Perl has dbi to fix that problem.
> 
> Python as its own DB interface defined too, including full 
> ODBC support.

Python's ODBC module should obviate much of ADO's slowness.
Use it if you can...
Although if your writing business objects, usually the overhead of ADO
disappears against your business rule validations.

Bill