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: http://git.infradead.org/evolution-ews.git/commitdiff/3e11452 ... 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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers