Re: Online Desktop and GNOME 2.22
- From: "John Stowers" <john stowers lists gmail com>
- To: "Owen Taylor" <otaylor redhat com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Online Desktop and GNOME 2.22
- Date: Wed, 31 Oct 2007 18:55:54 +1300
Hiya
After spending some time trying to integrate Conduit with
online-desktop lately, I thought I should share my thoughts.
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.
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.
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. web-login-driver is neither here nor there as
a solution, it adds another running daemon for very little benefit, as
the final step in the process (rewriting the cookie file so the
browser can pickup external logins) is not implemented.
The whole thing seems to depend on firefox/gecko quite heavily. How
does this fit in with gtk/webkit?
In conduit I use a simple site-specific-browser based on gtkmozembed
to log people into web services. mugshot can never see this login
because 1) I cant tell it about the embedded browsers cookie file
and/or 2) the above problems about not properly sharing logins between
all browsers means once I log into a site using the ssb, mugshot does
not propogate this login info to other browsers (for the reasons
mentioned in c) and being unable to rewrite browsers cookie files
underneath them and have them pick it up
d)
The mugshot GUI runs in the same process as data-model-engine. I
realise you are working to remedy this. It would be good if apps that
might be interested in the info on the gnome servers (gimmie and
conduit for example) didnt need to have mugshot gui running.
e)
Can you explain the relevance of pyddm if one can communicate with
data-model-engine over DBus to acomplish the same functionality?
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.
g)
Lets get some thoughts from the security folks on if it makes sense to
(for example) store private information on online.gnome.org using
http/https authentication
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
Anyway, apologies if any of these points appear negative. I totally
agree with the ideas of online desktop, I just disagree with some
points of its implementation
John Stowers (conduit developer)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]