SOAP support dropped from libsoup

Soon after I announced the release of gupnp-tools/av, someone pointed out that libsoup-2.4 is already out and therefore gssdp and gupnp needs to be ported to the new API. I am already done with the porting of gssdp and most of the gupnp (thanks to Dan Winship for being so helpful) but then came the shock: the SOAP support has suddenly been dropped from libsoup. I blamed my ignorance on me not being subscribed to libsoup ML so I started to dig into the archives but failed to find any mention of this change.

I know how to solve this issue and I am sure Dan will help me out in this one as well but IMO APIs should be deprecated first and then removed in the next major release.

Comments

Anonymous said…
I had exactly the same. I was using the libsoup SOAP support in a yet unannounced project when it was suddenly dropped. To fix it, I wrote a very small SOAP client myself that could do the things I needed. It's just a bunch of headers (so no full blown library), but they are C++. Ping me if you want to have a look at them, then I'll release those. - uwog
Anonymous said…
This is from the porting guide:
SOAP

SOAP support has been removed; the existing methods covered only a teeny tiny subset of SOAP, which was really only useful to a single application. (The code that was formerly in libsoup has been moved to that application.). If you were using this code, you can resurrect a libsoup-2.4-compatible version of it from revision 1016 of libsoup svn.
zeenix said…
Thanks but i had already read that before writing this blog entry, in fact thats where i came to know of this. I truely appreciate it that they put it in the docs but:

1. "only useful to a single application" part is not true at all (GUPnP relying on it and uwog's comment is enough proof against it) and I don't see any attempt of to finding out how many projects rely on it from the developers.

2. My main point was that the API should first have been deprecated and then removed.
Anonymous said…
It's true that I didn't discuss/announce this anywhere, but I did google around a lot (looking both for people talking about it, and using Google code search to try to find people actually using it), and I didn't find anything. (I guess google code search is not very reliable; it still doesn't turn up gupnp when searching for "soup_soap_message_new".)

Compare this to google code-searching for "soup_xmlrpc_message_new", which gets hits in several different projects despite the fact that the libsoup SOAP API had been around for 4 years and the XML-RPC API only 1.5 years. This seemed to back up my feeling that the existing
API was "only useful to a single application" (and even then, evolution-groupwise had a whole set of additional SOAP helper utilities built on top of libsoup's, because libsoup's were too
low-level).

As for deprecating it, there didn't seem to be any point, since AFAICT, it was only being used by evolution-groupwise, and as Olafur pointed out, if you really want the old code, you can just copy and paste it into your new app (and then make whatever customizations would actually make it more useful to you). And there isn't likely to be another ABI break any time soon, so "deprecate and then remove"
would basically have turned into "deprecate and then keep forever anyway". Whereas taking advantage of the 2.4 ABI break to get rid of the old SOAP API opens up the soup_soap_* namespace, leaving open the possibility of adding a better SOAP API in the future (if that's useful to libsoup's users).

(BTW, the other reason there wasn't much public discussion of libsoup 2.4 before it happened was because I assumed I wasn't actually going to finish it... :-) I'd been trying to find the time to do this stuff since GNOME 2.14, and it kept not happening.)
zeenix said…
Thanks for the explanation Dan and I understand why you decided to drop the API rather than deprecating it. However, I wouldn't rely on google search to see which projects are using a particular API of my library. To very least, an announcement on mailing-list would been a good idea, although it wouldn't have made any difference for me but i think Jorn is subscribed to it.

Popular posts from this blog

Welcome to the virtual world!

clutter-gst

zbus and Implementing Async Rust API