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) _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list