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
April 12, 2008 at 5:00 AM
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.
April 12, 2008 at 6:16 AM
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.
April 12, 2008 at 9:10 AM
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.)
April 14, 2008 at 7:41 AM
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.
April 14, 2008 at 12:46 PM
Post a Comment

Popular posts from this blog

Welcome to the virtual world!

Image
About two months ago I informed  the followers of this blog that I will now be working on SPICE project  for Red Hat . Judging from the questions I was asked after that, I realized that not many people know about SPICE so I thought I write at least one blog entry dedicated to explaining what SPICE is all about. Before I get to SPICE itself, let me first introduce you to the world SPICE lives in. Virtualization and Virtual Machines (VMs) For some reason, I feel that I should leave the definitions to wikipedia  and only quote it so that is what I am going to do: " Virtualization, in computing, is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system, a storage device or network resources. " " A virtual machine (VM) is a "completely isolated operating system installation within your normal operating system".Today, this is implemented by either software emulation or hardware virtualization ". V...
Read more

clutter-gst

After I was informed about the existence of ClutterGstVideoSink, I quickly modified my super-video application to make it use that. But as soon as i did that, i stopped getting even the static image. After careful analysis for days, I figured that I was supposed to call gst_bus_add_signal_watch() on the pipeline bus since ClutterGstVideoSink uses messages on the bus combined with signal handlers to render the frames in the application thread. This is obviously a 'dirty' hack; a hack because gst elements are supposed to do all the media processing in the pipeline thread, dirty because gst bus is not meant for media transport. After this realization, I had been working on it from time to time. First I tried to make the actual rendering happen in the gst pipeline thread by using the clutter's thread safety primitives and that worked quite nicely in the end except for one minor problem: The call to clutters rendering thread blocks if it happens after the clutter main loop has b...
Read more

Shame Ubuntu shame

I am no more a fan of Ubuntu. The reason is their recent demonstration of lack of community spirit. Here is the release announcement of Ubuntu hardy alpha6. If you scroll-down you can see the gnome-system-monitor's new cool "Resources" view featured with a nice screenshot. Since Karl-Lattimer worked really hard to make this happen, he asked to be given personal credit on that page. Don't know about others but I see this as a very reasonable thing to ask. The result of this request can be seen in the announcement of hardy beta. They just removed the feature from the announcement. Shame Ubuntu shame. UPDATE: It's interesting how most of the comments that are from people who got pissed without actually caring to understand the main point of this blog entry (which me and Karl-Lattimer tried to emphasize in the comments) are posting as Anonymous. :) Acknowledging the possibility that they might not think comments are worth reading before commenting, let me make it c...
Read more