Cart
[Home] [By Thread] [By Date] [Recent Entries]
Kevin, I might be wrong but I think we are getting mixed up between pure IDL and inplementing an API that uses Microsoft's IDispatch interface. IDispatch is limited by VARIANT types and LPUNKNOWNs but IDL and even COM for that matter is not. Even if Alex passes a pointer to a stream or some other object, that object can be wrapped with IUNKNOWN if you are trying to provide a COM interface for the object. I know that it's easier to provide a COM interface using IDispath and basic types but I think it's just far too limiting for an API. Maybe we should let the interface be designed in Java first and worry about the IDL later. :) Chris Lloyd From: Kevin Grimes@LIANT on 06/23/97 06:30 PM Limiting the types used in the Java XAPI to basic Java types like int, boolean, String, plus the Java interfaces that you've actually implemented in Java (IElement, IXMLProcessor etc.) will make the job of porting the Java XAPI to IDL easier. InputStream was the first thing I tripped over when I translated my Java APIs into IDL--to avoid defining an InputStream interface in IDL I rewrote the member function processDocument to use String. Here is my version of xml.idl. This is my first use of IDL, and XML, and Java for that matter, so please let me know if I'm doing something stupid. I compile this with the MIDL compiler that comes with Microsoft's Visual Studio. We have C++ and Java clients that implement the IXMLApplication callbacks or use the IGrove and INode interfaces to traverse the parse tree. Regards, Kevin (k.grimes@l...) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...)
|
