Re: Re[2]: [xml] [PATCH] Patch for https(ssl) support

["Igor Zlatkovic" <igor zlatkovic com>]

>   Hum, if you, Igor and Marc are all 3 interested in getting it in,
> that having it disabled by default if fine for you, and you agree on a
> common patch, then I would apply it, unless there is strong disagreement
> from other interested parties.

I personally don't have the HTTPS requirement anymore. I had one some time
ago. Your arguments about unwanted dependencies on other libraries and
Bjorn's arguments about that leaving the sphere of a XML processor's duty
convinced me that it would be better to plug an own IO handler, just like
Mark did.

I don't like too many dependencies myself. When I install something that
depends on three other things, then I must get them all and all their
dependencies, compile everything in right order, perhaps fix something that
won't compile, and watch what for a mess is being installed. There exists no
ease of rpm.

I also strongly agree with Bjorn's view. The system should be a set of tools
which can communicate in a standard manner, each of them doing exactly one
thing and doing it well. Using a myriad of programs which do everything and
need nothing save the OS kernel is a mess. It makes headaches, wastes
resources, duplicates functionality, triplicates bugs.

The odd thing is that the two paragraphs above contradict and a reasonable
balance must be found. The HTTP and FTP support in libxml is bearable. Even
if there are other tools which do it far better, libxml has the bits it
needs. Doing a SSL/TLS is another thing, it cannot be implemented without an
external library. One cannot do the strong crypto with 10 algorithms and the
key management in one C file. At the far end, it is not just HTTPS. You can
encapsulate almost any protocol in a secure layer, which obscures and
authenticates. Why not FTPS as well? Or IMAPS? How long before SCP?

Convinced by you and Bjorn, I believe that the line should be drawn
somewhere. SSL/TLS is too much to bear. We can put it at the backs of
programmers who need it and have them write their own IO handlers. Or
better, we can go Aleksey's way and provide an interface for IO plugins
which can be loaded at runtime and if a plugin is not there, it's
functionality will simply be missing, no more, no less. Such a plugin does
not put any dependency in libxml, it puts some in the plugin, and libxml
lives with or without the plugin.

Ciao,
Igor