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

Hello there,

  Okay I think there is a need here. First I don't know the 
Windows platform,
Igor is the maintainer, but so far its role is limited to 
make sure the 
damn code compiles on Windows and packages binary ready distributions.
However, it appears to me that most of the people coding in 
the Windows
world expect COM (or DCOM but let's be reasonable first) 
packages available
to integrate a library in their development process.

I cannot speak for everyone, but the main reason I started using libxml
back then is its lack of COM interface. I wanted a program which
compiles across platforms with the least hassle. Just by using COM, no
matter what, you are limited to Windows forever. Know there are COM
implementations for Linux but those who actually use this can be counted
on fingers, worldwide.

  I have the horrible feeling that most of the libxml2/libxslt Windows
users did as a first step of the integration of the library 
in their project
a COM wrapper. And I also sense that the Right Thing to do at 
this point is
to try to provide a standardized COM module for those libraries.

Not most users. Most beginners have tried this, because that is the only
way they knew. None of these who crossed my way posessed knowledge
enough to compile a hello-world DLL and load it in a hello-world

I can give you the COM wrapper, no problem. This is a time-consuming
task as libxml has 800+ functions, but it is easy. Everyone can do that.
I would however be the first one not using it. Speaking to libxml
through COM (and particularily DCOM) would mean few things:
 * Memory allocation of data which goes through DCOM may not be done
using malloc, but through CoTaskMemAlloc() or the system's IMalloc
interface. The wrapper would have to handle this. 
 * All character string traffic which goes through DCOM would have to be
BSTR (length-prefixed Unicode string) format.
With all that MSXML would perform better, in addition to being
automatically available on all recent Windows installations.

On the other side, my code using libxml through (D)COM would now work
only on Windows. Libxml would have no real advantage over MSXML to me. I
believe that exactly the C interface and availability across platforms
is the primary strengh of libxml on Windows.

Just to add that Microsoft's current staregy is discouraging any further
use of COM. They now put all their expectations in .NET and the defeat
of Java :-)

  I understand that most users in the Windows world may be on tight
and focused schedule and have hard guidelines w.r.t. sharing code or
intellectual property, but I would like to be sure you can point and
expose that sharing such work can make real business sense, 
remember that
user early this year developping W3C C14N abd XML DSig and who did not
share his code ? Well now Aleksey provided such an implementation, it
got integrated and is getting a lot of momentum ATM, so that 
early implementor
who did not share his code simply has to continue maintaining it and 
doesn't get feedback or bug fixes, or even worse at some point must 
change his code base to resuse the native code, at that point 
he has lost
all the code knowledge which could have been his advantage if 
he had been
part of the team designing the solution integrated as the 
default in the

  I don't want to frigthen or force people to work on this 
(just the contrary
I explicitely selected a Licence where you are guaranteeed I 
cannot enforce
anything on my users), but I would like the Windows users 
community to realize
that building and sharing a common default COM wrapper object might be
in everybody's best interest and that I would really welcome 
Mark, Igor and
other people in that situation to drive such an effort. 

I can see nothing in our MS licences that would prohibit me to write a
COM wrapper for libxml and publish it under LGPL and/or MITL. It is a
question of will, not licence. I'll help developt the thing, of course,
I will even develop it alone if need be, but I will not use it.

Maybe I'm just
totally off-track w.r.t. what COM is or the possibility of agreeing on
a common object model, in that case feel free to hit me with your
preferred clue bat !

I'll post another message now to clear the situation... :-)


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