Re: Online Desktop and GNOME 2.22

[Dan Winship <danw gnome org>]

Colin Walters wrote:
> On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote:
> > H
> > Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see 
> > if there's anything missing?
>
> This looks good overall.
>
> Are there any libsoup python bindings?

No, no one has ever asked about doing bindings of libsoup before, 
probably because every other language already has its own standard http 
library. But of course, none of them have glib main loop integration and 
stuff like that.

It's mostly GObject-based, so it shouldn't be too hard to bind, although 
there are some warts like the "authenticate" signal that was discussed 
(or rather, mocked :) on gtk-devel-list last week.

I should try this out now to see what problems turn up.

(Isn't online desktop currently doing all of its HTTP from C? Are you 
wanting to move it to Python, or is this for somewhere else, or what?)

> By far the most important thing from my perspective is read-only
> cookies.  I am sure there are use cases for cookie modification, but it
> seems more specialized.  I certainly wouldn't want to have writable
> cookies by default because it seems likely to "break the web" as
> sessions get overwritten, etc.

Hm... do read-only cookies really work? What if the site tries to send 
you a new value for the cookie? (I guess the app can update its local 
copy of the value and just not write it to the global store.)

It seems like "sessions getting overwritten" could be a problem either 
way though. Like, if you have a cookie representing a shopping cart, 
having two different processes both trying to use it seems like it could 
result in things appearing and disappearing from the cart at random. And 
the user probably won't expect that logging out of the web site in the 
browser would also affect other apps accessing that service.

If shared cookies is mostly about authentication, then does it make more 
sense to just fall back on shared passwords, and let each app get its 
own cookie/session? (You'd have to hardcode some info about how to log 
in to each service without the user actually using its web UI, but you 
have to hardcode other things about the service already anyway...)

Doesn't Windows (or at least IE) have cookie sharing to some extent? 
What do they do?

> A cache is also a requirement for some of the things we've been
> prototyping in online desktop; it doesn't necessarily have to be shared
> with the browser, though that would be nice.  

Right, I noticed that you have your own cache now.

> Does libsoup support concurrent access?  This would also be critical for
> online desktop.

Yes. A given SoupSession can be accessed from multiple threads, and you 
can also have multiple SoupSessions if you want to completely isolate 
different parts of the app.

> A concurrent cache is fairly straightforward; concurrent SSL certificate
> database I don't really want to think about =)

Fortunately, you don't have to because they already wrote it. :-) (Using 
sqlite.)

> Overall, the libsoup approach + browser integration hooks does have the
> disadvantage though that it will have to follow browser changes (e.g.
> cookies in Fx3 are now in cookies.sqlite) and just in general be another
> HTTP implementation besides the one in the browser.
>
> The ideal world would have a nice gobject/glib async interface
> (+Python/C#/Java bindings) which would wrap the same library used by the
> browser (necko, whatever gtkwebkit uses, etc.).

I doubt necko is API-stable, so we'd have to play keep-up on each new 
release anyway. And just using the browser's library doesn't solve the 
problem of *sharing* its data if that data wasn't meant to be shared.

After Havoc's comments, I started thinking about the idea of having a 
Firefox extension that makes Firefox act as an HTTP proxy server. Then 
you point your other HTTP-using apps to that proxy server, and they 
automatically end up sharing Firefox's cache, cookies, and proxy 
settings. (Passwords and certs would still need to be handled 
separately.) Of course, you'd want this to work when Firefox wasn't 
running too, so what you'd end up doing is having the proxy server run 
as a separate process (a xulrunner-based app with no UI?) and then have 
Firefox talk to it. (And you'd have some Firefox extension that would 
make it use no disk cache, etc, on the UI side, but the prefs dialog 
would show the amount of cache being used by the backend, etc.)

I can't decide how crazy this is... Part of it would depend on the 
concurrency stuff. You don't want the web browser to block because the 
weather applet is updating.

-- Dan