I've just been reviewing the e-soap-{message,response} API, and I don't
like it much.

Some of our responses can be *huge* — the whole of a MIME message will
be base64-encoded and included in the XML response.

Yet we allow libsoup to gather the whole message into a SoupBuffer, and
then we parse that into an xmlDoc so we have *two* copies of it in
memory, at least for a while.

I don't want *any* copies of it in memory. So for a start I've changed
things to parse the response as it comes in, and we only have one copy:
... and I'll be working on using the SAX interface to libxml2
(optionally) so that we really can spool the <MimeContent> node to disk
as it comes in and not have *any* copies in memory.

We're going to have similar issues with outgoing requests, too. When we
call the Exchange server's CreateItem method, we'll need to include the
full MIME message in our *request*, and we'll want to stream that too.

Anyway, since nobody is actually *using* ESoapMessage and ESoapResponse
in 3.0, because the GroupWise code hasn't actually converted to it yet
and is still using its own private SoupSoapMessage/SoupSoapResponse, I
think we should rip it *out* of the 3.0 release, and put it back into
3.1 when it's finished. For now it can live in evolution-ews, which has
a copy anyway so that we can build that for 2.32.

Chen, what do you think? Could you rip it out before you do the release
on Monday? Matthew suggests not bothering to bump the libedataserver
soname, since "that's just gonna cause havoc at the 11th hour over
something no one is using".

David Woodhouse                            Open Source Technology Centre
david.woodho...@intel.com                              Intel Corporation

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to