Re: Online Desktop and GNOME 2.22

[Havoc Pennington <hp redhat com>]

Hi,

John Stowers wrote:
> a)
> The build provess for hippo
> (http://svn.mugshot.org/dumbhippo/trunk/client) is overly complex on
> account of things for windows and osx in there. This includes a
> dependency on firefox and a huge bunch of statically built libraries.
> This seems a bit excessive.

The system copies of the libs are used on Linux. We do need to figure 
out some kind of directory rearrangement so you don't have to check them 
internalized copies out of svn on Linux. But, I don't think there is any 
non-developer impact here. The negative is purely that right now the svn 
module has a bunch of stuff in it irrelevant to Linux taking up disk space.

Suggestions are welcome. I don't think windows portability is a negative 
though, any more than it is for gtk or gimp or whatever.

> b)
> There is no way to login to programatically to online desktop using
> either the dbus api or another manner. This is different to many many
> other web apis and makes it difficult to reliably use the api from
> outside mugshot.

We discussed this some in private mail. I'm still not really 
understanding what you mean.

The way you're doing other APIs is that you're using a model where 
individual apps log in to web sites.

Our model is that the whole desktop - i.e. the data-engine daemon - logs 
in to online.gnome.org, and no other app needs to log in.

I think it's clearly a downgrade/sucky if every app has its own login 
dialog and you have to log in 10 times if 10 apps use the data engine.

As I said in private email, we can have an API where you can supply the 
login cookie, so you could open online.gnome.org/who-are-you, log in, 
get the cookie, and give it to the data engine thus logging in the whole 
desktop. But, this is obviously a hacky workaround for the fact that the 
browser used in your app is not sharing cookies with the user's main 
browser in the first place.

But, I think easier and just about as good is to simply do "gnome-open 
http://online.gnome.org/who-are-you";

You really need not worry about this at all in theory, because a 
reasonable "online desktop" default config will have a big login button 
on whatever its panel thing is (bigboard, gnome-panel, whatever) if the 
user is not logged in to online.gnome.org. So individual apps don't need 
to offer login at all really.

What I think would be wrong is to have multiple login states, i.e. have 
a situation where one app is logged in but not another app.

> c)
> Continuing on from the above point, the current method of monitoring
> and parsing the cookie file to log in, while cute, is not something I
> totally grok. While I see the point of it all (login once, and then
> access the services from any app) It never gets close to solving the
> real problem, sharing authenticating information from the browser with
> the rest of the system.

I don't understand what you mean here. (I don't know why we want to 
share auth info from the browser with the rest of the system.)

> web-login-driver is neither here nor there as
> a solution

web-login-driver has nothing to do with the login of the data engine to 
online.gnome.org. All it does is potentially "prefill" login info for 
non-online.gnome.org sites, see bigboard/bigboard/accounts.py

> The whole thing seems to depend on firefox/gecko quite heavily. How
> does this fit in with gtk/webkit?

The cookie thing does not depend on those heavily, it supports a couple 
of browsers and is easy to extend to support more.

If we eventually implement what I think is the real solution, that all 
apps on the desktop share the same http stack (meaning, cookies, proxy 
settings, and cache), then there may be some work to get the different 
browser engines supporting the same cookies/proxy/cache/etc. How hard it 
is I don't know. But work like this is the price of diversity, and if 
nobody does the work apparently the diversity is not worthwhile.

> d)
> The mugshot GUI runs in the same process as data-model-engine. I
> realise you are working to remedy this.

Right.

> e)
> Can you explain the relevance of pyddm if one can communicate with
> data-model-engine over DBus to acomplish the same functionality?

pyddm is a python library that communicates to data-model-engine over dbus.

> f)
> Work is ongoing in Conduit to make it play nicely with OD. We should
> have some things to show soon (minus gross login hack due to b+c. Lets
> talk about standard places in online desktop where we can store
> peoples login names to different sites (i.e what is my flickr
> username). This is probbably a documentation issue where object paths
> and such just need to be spec'd out somewhere.

I would like to do this with an approach similar to 
bigboard/bigboard/accounts.py - see recent thread on the online desktop 
list - but in short, I think the flickr username should be in gconf, and 
the flickr password in gnome-keyring. Then we use the online prefs sync 
feature to sync the gconf username, and we need to implement a sync of 
the encrypted keyring blob.

Well, refining that a bit, we do store the flickr username on 
online.gnome.org already; but the way it's done seems a little 
mugshot-oriented and maybe doesn't make sense for o.g.o. Not sure.

> h)
> Another canvas library (yes Its staticly built, and yes I am also
> guilty of using another canvas lib - goocanvas) but how is the gtk
> canvas unification/blessing process going?. As an aside I guess this
> becomes a non-issue if d is solved

This is a huge intractable problem, see related to gtk-devel threads. I 
won't try to solve it ;-) I will note that the HippoCanvas is IMO 
different in what it's optimized for, vs. something like GooCanvas. See 
the gtk-devel threads.

Havoc