Newbie biting off more than he can chew, can you lend some molars?

[Alex Martelli]

<dwelden at my-deja.com> wrote in message news:8tkkht$40j$1 at nnrp1.deja.com...
    [snip]
> The module is a wrapper for a collection of dll's that interface with
> the Hyperion Essbase OLAP Server. The OS for which I am interested is
> Windows NT, but it also works with AIX, Sun, etc. The module can be

I suspect your best bet is to interface to Hyperion Essbase through
COM (aka ActiveX), a technology which apparently they also support (as,
on NT, one would have to be crazy NOT to support:-).  Python, with
Mark Hammond's win32all extensions, works very well with most COM
servers (if custom, non-standard, non-automation interfaces are to be
handle, a little bit of C++ level work to extend the pythoncom module
may be needed, but that hardly ever happens, in my experience of COM
servers... functionality is virtually-always exposed through 'dual'
interfaces, which Python is good at, and accompanied by type libraries,
which can be analyzed by the makepy auxiliary script to enhance the
interfacing 'depth'.

One specific possibility is using ADO, the application-oriented part
of Microsoft's Universal-Data-Access architecture (the lower-level
part of which is OleDb); one thing ADO is particularly touted as good
for (I have no experience in that, but it does seem to make sense)
is interfacing to OLAP servers, and I've heard Hyperion Essbase given
as a specific example in this context.  Python, of course, is good
at driving ADO (ADO, after all, being nothing but a typical COM
object model, exposed through automation-compliant dual interfaces).

(For platform-independence one might want to look into whether
Hyperion Essbase can be accessed via CORBA -- Python is quite
good at talking Corba, too -- and only as a last-ditch would one
consider porting C-level code intended to interface to Perl, IMHO;
it's probably easier to wrap some C-level interface via SWIG...).


Alex