Re: [xml] Providing standard COM modules (Was: [xslt] Thread safe?)

My $0.02: I agree with Igor that creating COM envelope for LibXML2 will have a big
performance penalty unless it'll be decided to push all the Windows stuff
(Unicode, etc.) deep inside the library. I used to port C code to a COM server once and at the end it was decided to re-write eerything from scratch because
of unacceptable data marshaling performance penalty. IMHO, the only reason
to use LibXML2 on Windows is to have cross-platform code and COM kills
this advantage. I can understand why COM should be used when you are creating some kind of Windows service (printer service, for example) but I do not see
what COM API will add to LibXML2. At the end of all, using COM is not
more simple than using DLL (or better static .lib file). Probably good LibXML2
documentation will help much more.

If there are smart guys who have nothing to do then I have another suggestion:
create a native C++ wrapper for LibXML2/LibXSLT. I already heard few
complaints from C++ programmers that it's very difficult to use LibXML2 and
write good C++ code. These guys want to have iterators, algorithms, etc. And creating a simple C++ wrapper is the first thing C++ guys do with the library. I've already
seen two ugly wrappers (well, both serve the purpose). I think that creating
a good native C++ API will make LibXML more popular in C++ world
(including KDE guys)  But it is not a simple task :(


Igor Zlatkovic wrote:

Okay, let me hear voices:

Who would benefit from a DCOM interface, if libxml2 had one? Please respond, I need a picture of how many people would use this.

xml mailing list, project page
xml gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]