Re: random usage notes from a libsoup newbie

[Dan Winship <danw gnome org>]

Benjamin Otte wrote:
> So, I thought I'd post all the stuff that came to mind during my
> recent experiences with libsoup. Maybe it's useful.

Very. Thanks! I'm mostly responding to just the actual *questions* here, 
but I'm pondering all the comments too.

> - Without the tutorial in the beginning of the docs I would have been
> lost. The naming of the most important object seems a bit unfortunate;
> a "message" to me is means something else.

Hm... well, that's the standard HTTP terminology, and with the current 
API, you can't really get away from having to know a bit about HTTP. 
(Lots of people have requested a simpler API though, that abstracts away 
more of the details.)

> - I'd love if there was a default session, just like there exists a
> default glib context. I have no clue if that makes sense.

Maybe, but would it be a SoupSessionAsync or a SoupSessionSync?

> - I'd really like to know more about what sessions are useful for.
> Should there be one per application? One per thread? One per message?
> Why would I want to create a new one?

One per anything-that-you-can-only-have-one-of-per-session. The original 
motivation was multiple user accounts in the Evolution Exchange backend. 
With libsoup 1.x, evolution-exchange could only allow a single user 
account, because there was no way to tell libsoup to use one 
username/password for some requests and a different one for other 
requests. (This was using NTLM, where the actual connections are 
authenticated, not just the requests themselves, so you can't just keep 
passing the username/password in the request URI.) Now it uses a 
separate SoupSession per ExchangeAccount.

There are a few other reasons you might need multiple sessions, like if 
you have multiple GMainContexts in different threads, and you want to 
use soup asynchronously in each of them, then you'd need a different 
session for each one. But it's true that most apps will only need a 
single session.

> - The API looks very old. I assume it was ported to GObject as an afterthought?

Yeah, see the "soup" module for the pre-GObject version.

> - I'm missing gobject properties...
>
> - I also get confused by the basic objects not being opaque...
>
> - SoupOwnership still confuses me...

Yeah, all remnants of the original API.

> - Since I needed progressive loading I connected to the got-chunk
> signal and tried to use soup_message_pop_chunk(). I still haven't
> figured out what that function does. Does it even work? Apparently I'm
> supposed to use msg->response directly. At least that works fine.

Yeah, that's the right way to do it. soup_message_pop_chunk() is an 
internal method and shouldn't even be documented/exposed. (When you're 
implementing a SoupServer, and are sending a response back to the client 
in chunked encoding, you use soup_message_add_chunk() to add chunks to 
the response body, and the HTTP I/O layer uses soup_message_pop_chunk() 
to retrieve them. Hm... nice parallel naming there: add/pop.)

> Keep up the good work and pimp libsoup more, please. People need to
> get rid of curl or gnome-vfs for http. ;)

So here's a question: which would be better, getting libsoup into the 
platform soon, warts and all, or taking advantage of its position in the 
desktop to break its API first to fix some of the things you talked about?

-- Dan