On Wed, 2007-10-31 at 18:55 +1300, John Stowers wrote: > 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. The included versions of libraries are only used when building on Windows, so the only real downside is the size of the checkout. We'll separate them out before moving our stuff into GNOME svn. > 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. I don't quite understand this point. The general idea is that the user *is* logged on, and we barely even support logging out ;-) The general expectation would be that not being logged in is pretty much the same as being not connected to the internet. But assuming that we fix the lack of a working log out UI, I could see the need for a D-BUS API to backend a dialog: "Conduit needs you to be logged in to online.gnome.org to perform this operation. Log in now?" [ Cancel] [ Login ] Where Login would prompt you for authentication. Is this the kind of thing you are looking for? > 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. I think you are mixing together two different things here: - The way the mugshot client logs into mugshot.org and/or online.gnome.org. - Our attempts to improve the general problem of authentication to services across the desktop. (web-login-driver is part of that) I guess, to some extent, online.gnome.org *is* just another service, but we're not really considering it that way. We consider the instant notification aspects of what we are doing an integral part, and the natural way to do that across the desktop is to have a single daemon log in once, rather than have each client open a separate XMPP connection to online.gnome.org. Adding a more standard web-services API for third party access to online.gnome.org is certainly 100% possible; I even have some code started for that around somewhere. It's just not a priority for us at the moment, since we're focused on the use of online.gnome.org inside the GNOME desktop. > The whole thing seems to depend on firefox/gecko quite heavily. How > does this fit in with gtk/webkit? The worst possible thing would be the appearance of gtk/webkit slowing down new desktop features by making everybody pass a "does it work with webkit" gauntlet. Let's put our efforts into making something cool. If people want to add webkit support, then so much the better. > 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 Within the context of Conduit, I don't think you should be thinking of the online desktop as an internet web service; it's a desktop service accessed over D-BUS. So, I don't see a need for you to present a login dialog embedded within Conduit. In terms of improving the general situation of improving access to browser cookies and authentication outside the browser: the more people working together to fix that problem, the better! > 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. Yep. > e) > Can you explain the relevance of pyddm if one can communicate with > data-model-engine over DBus to acomplish the same functionality? If you examine the D-BUS protocol for the data model, you'll find that there is no way that you want to deal with it directly. pyddm is a python library that provides a convenient API on top of the raw protocol. We also provide a C library for the same purpose, and Havoc started a C# version. (Alp picked that one up.) > 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. Cool. > 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 To some extent, that's the sort of thing that needs to be discussed type-of-private-information by type-of-private-information. I don't think there's going to be a single answer. But certainly an important discussion to start having. > 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 Not a lot of progress there that I'm aware of. But HippoCanvas is just an implementation detail of our two GUI apps ... the Mugshot client and the Bigboard. I don't think it has much importance for other people that want to consume the online.gnome.org data model, on way or the other. > 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 I appreciate your mail; it's great to have other people trying to work with our services and finding out what works for them and what doesn't. I hope the above makes it more clear how we see access to online.gnome.org integrating with the desktop. - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part