[wsf-c-dev] External dependencies

[James Clark]

> >- External dependencies.  Which external libraries should we take a
> >dependency on and how dependent should we be on them? libxml2 and curl
> >are two obvious candidates.

I should also mention openssl.

> >
> As I remeber we talked about writing our own parser embeded into axiom.
> So that removes dependancy on libxml2. How about improving our
> own transport instead of using curl which will save us from another
> dependancy?

We should be aiming to maximize reuse.  The way to create something
really valuable with the minimum amount of work is to figure out the
right things to reuse, and spend effort only writing stuff that really
adds value beyond what is out there already.  Rewriting everything from
scratch is good, clean fun, but it's a poor way to create business
value.

Both libxml2 and curl represent a huge amount of good-quality work,
under an acceptable license (MIT).  We need to have a good reason *not*
to reuse them.  We should only duplicate their functionality to the
extent that we gain some substantial benefit by doing so.

Let's start with libxml2.  It's strength is that it provides full,
compliant, general purpose implementations of important specs (XML,
XPath, XPointer, XSLT, DOM). But this strength is what provides the
opportunity for doing better.  We can potentially provide significantly
better performance than libxml2, by creating implementations that are
specialized to our needs.  For example, SOAP imposes significant
restrictions on XML.  It makes sense to look at doing a XML parser that
leverages those restrictions to achieve better performance. In cases
where we need full XML 1.0 compliance, we could fall back to libxml2.
Our consider XPath.  XML Security requires full XPath support, which
requires building a DOM, which is incredibly slow.  But I'll bet that
99% of the time, the use of XPath in XML Security is very simple, and
could be handled with a streaming implementation.  So it would make
sense to do our own streaming implementation of a small XPath subset,
and fallback to libxml2 in the few cases where a full XPath
implementation is needed.

Another perspective on external dependencies is in terms of platform
integration.  On Linux, libxml2 is in practice the standard platform
implementation of DOM.  For an application that is working at the XML
level, the concrete representation of XML that the application is most
likely to be using is libxml2's DOM.  We see this in PHP, where
SimpleXML is using the DOM.  So from a platform integration perspective,
it's important that our stack can efficiently accept a payload that is
represented as a libxml2 DOM.

But Linux isn't the only platform we need to support.  This brings me to
what I believe is an important requirement on the way we deal with
external dependencies.  Wherever possible, we should make these external
dependencies pluggable.  On Windows, MSXML plays a similar role to
libxml2.  Windows apps are most likely to have their

Curl is a good example. That's a great solution for Linux.  But Windows
has a couple of HTTP client libraries (WinHTTP
http://msdn2.microsoft.com/en-us/library/aa384273.aspx and WinINet
http://msdn2.microsoft.com/en-us/library/aa385331.aspx).  On Windows we
ought to be able to plug these into our stack.

In other words, I think we should be aiming for deep platform
integration.  Many open source programs work less well on Windows than
on Linux.  They behave like Linux programs ported to Windows and not
like native Windows programs.  Our goal should be to make our stack
perform as well on Windows as a stack written to run on Windows
exclusively, and similarly for Linux.

James