Re: Online Desktop and GNOME 2.22

[Colin Walters <walters redhat com>]

On Tue, 2007-11-27 at 13:35 -0500, Dan Winship wrote:

> 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.

Right.

> 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.

Try out creating Python bindings?  That would be awesome!

> (Isn't online desktop currently doing all of its HTTP from C?

Most of the stuff we're prototyping is in Python, though there is a bit
of HTTP from C.

> 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.)

Right, or just ignore it.  

One angle I'm trying to approach infrastructure bits from is "What is
hard about writing a GMail feed display?".  You can get the GMail Atom
feed as long as you have the authentication cookie.  Playing around with
the Google widget for the Vista sidebar on Windows, the way it works
(educated guessing here) is that the applet tries to do a HTTP request
for the feed; if that fails, it displays a link that says "Sign in to
GMail".  The link directs you to https://mail.google.com; when you sign
in there, the session cookie is set, the applet redoes its request
(ideally there would be notification here, but I bet it polls), and gets
the feed.

So far it seems most projects when faced with this issue are taking the
approach of prompting the user again for username/password, but that
sucks for a variety of reasons.  Though I have a start on a system for
making that better: http://live.gnome.org/OnlineDesktop/WebAccountSystem

> 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.

I don't really see why one would want to write a full desktop
application for something like a shopping website.  The cookie sharing I
see as mainly targeted for "widget" type read-only notification
components.

> 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...)

Well, the hardcoding here is getting into the screenscraping level
because the saved passwords are based on the HTML form field names.
Granted I have this in web-login-driver but we're more recently trying
to go with the WebAccountSystem approach.

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

Yeah.  IE is actually built on WinINet which implements the caching and
cookies: http://msdn2.microsoft.com/en-us/library/aa383630.aspx

So if your application uses the WinINet API you get both for free.
WinINet is truly awful in other ways (the async API in particular), but
that part is nice.

> > 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.

I guess the challenge would be to maintain that threadsafety while
adding caching and cookie sharing.

> > 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.)

Hm, in my Fx3 build I don't see either of those components using sqlite.
Using SQLite as an index would give you a working model for concurrent
access to a cache though.

> 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.

Right.

> After Havoc's comments, I started thinking about the idea of having a 
> Firefox extension that makes Firefox act as an HTTP proxy server. 

I think this would have too many user-visible weird side effects.

> 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.)

In the longer term it probably does make sense to have a daemon process
of some sort that can act as a proxy so that apps which aren't written
to libsoup could take advantage of the cache, etc.

In the shorter term though my requirements list is leading me more
towards libsoup + inotify monitoring of firefox cookies.sqlite.