Re: Online Desktop and GNOME 2.22
Colin Walters wrote: On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote: A concurrent cache is fairly straightforward; concurrent SSL certificate database I don't really want to think about =) Many appologies for the awkwardly late response, but... gnome-keyring will do this for you in 2.22 :) All nice, concurrent shared certificate/key store, and usable by NSS (ie: Firefox) and other libraries. http://live.gnome.org/GnomeKeyring/CertificatesKeys http://live.gnome.org/GnomeKeyring/ApplicationSetup Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote: H Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see if there's anything missing? This looks good overall. Are there any libsoup python bindings? By far the most important thing from my perspective is read-only cookies. I am sure there are use cases for cookie modification, but it seems more specialized. I certainly wouldn't want to have writable cookies by default because it seems likely to break the web as sessions get overwritten, etc. 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. Does libsoup support concurrent access? This would also be critical for online desktop. Which, taking a step back, is actually the really hard part about most of desktop/browser HTTP integration. As far as I know, all mainstream browsers are not concurrent (threads may be used to make some operations async, but that's not the same thing exactly). According to this document Necko is not threadsafe: http://www.mozilla.org/projects/netlib/necko_threading.html A concurrent cache is fairly straightforward; concurrent SSL certificate database I don't really want to think about =) Overall, the libsoup approach + browser integration hooks does have the disadvantage though that it will have to follow browser changes (e.g. cookies in Fx3 are now in cookies.sqlite) and just in general be another HTTP implementation besides the one in the browser. The ideal world would have a nice gobject/glib async interface (+Python/C#/Java bindings) which would wrap the same library used by the browser (necko, whatever gtkwebkit uses, etc.). Realistically though, trying to unify HTTP libraries is a huge amount of work; the payoff would be fairly large, but what we need right now is a HTTP library with: * Async interface * Concurrent access (multiple processes and threads) * Caching * Readonly cookies from browser * Python bindings ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Colin Walters wrote: On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote: H Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see if there's anything missing? This looks good overall. Are there any libsoup python bindings? 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. 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. (Isn't online desktop currently doing all of its HTTP from C? Are you wanting to move it to Python, or is this for somewhere else, or what?) By far the most important thing from my perspective is read-only cookies. I am sure there are use cases for cookie modification, but it seems more specialized. I certainly wouldn't want to have writable cookies by default because it seems likely to break the web as sessions get overwritten, etc. 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.) 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. 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...) Doesn't Windows (or at least IE) have cookie sharing to some extent? What do they do? 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. 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.) Overall, the libsoup approach + browser integration hooks does have the disadvantage though that it will have to follow browser changes (e.g. cookies in Fx3 are now in cookies.sqlite) and just in general be another HTTP implementation besides the one in the browser. The ideal world would have a nice gobject/glib async interface (+Python/C#/Java bindings) which would wrap the same library used by the browser (necko, whatever gtkwebkit uses, etc.). 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. After Havoc's comments, I started thinking about the idea of having a Firefox extension that makes Firefox act as an HTTP proxy server. 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.) I can't decide how crazy this is... Part of it would depend on the concurrency stuff. You don't want the web browser to block because the weather applet is updating. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
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
Re: Online Desktop and GNOME 2.22
On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote: Havoc Pennington wrote: I do think libsoup, gnome-vfs, neon, and curl are all bad answers long-term for apps that want to use web APIs or download an icon. The right answer will address among other things how to share cookies and proxy settings and cache with the browser. Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see if there's anything missing? And IMO should just be HTTP, not SOAP or DAV. So this is a good problem for someone to try to solve. So, I'm not sure if you're being misled by libsoup's name (and heritage), but it IS just HTTP. (The SOAP support was ripped out for version 2.0, and while there was a little bit of soap stuff added back later, it's totally peripheral.) While I agree that no existing HTTP library does all of the integration you discuss (even using mozilla's HTTP layer is no good because it still can't *share* all the data with Firefox), it seems like it would make a lot more sense to take a working HTTP library and build on that, rather than writing a new one from scratch. (Unless you're thinking that the best solution is to proxy all HTTP calls to Firefox over D-Bus or something?) The ones we would care about for Totem and other media players would be passwords and cookies (and to a lesser extent certificates in a few cases). The problem is that we usually use gnome-vfs to access HTTP resources, and moving to gio/gvfs would either need an HTTP module there, or a library that offers similar features. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Hi, Dan Winship wrote: Havoc Pennington wrote: I do think libsoup, gnome-vfs, neon, and curl are all bad answers long-term for apps that want to use web APIs or download an icon. To be clear, I wasn't trying to say here that none of these could be made a good answer, just that they aren't now due to the browser-state-sharing issue (or e.g. gnome-vfs deprecation, etc.). I would not say writing an http lib from scratch makes sense. The main other approach I was thinking of was to in some way use the Firefox http implementation, either via a dbus daemon or just via a shared library. Alex had some thoughts along those lines too. Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see if there's anything missing? It looks pretty good to me though I am not an expert. I think from what you wrote it's pretty clear that modifying Firefox itself is a required part of a good solution. Some offhand thoughts that may suck: - making the codepath different depending on whether Firefox is running sounds like a direction that would have user-visible weird effects and also make app authors uncomfortable - it seems inevitable that both gnome-http-lib and Firefox would need to rely on some type of common repository of cookies, etc. and that this repo would be managed by some type of daemon that handled locking and change-notification; said daemon would need to be able to run sans Firefox, and would need to handle changes to the repo, not be read-only. - though it never pays to block on a committee, I would say key people to get sign off from (or at least keep informed) would be Alex so we know the solution works for gvfs, and the Mozilla team, so we know they will take the patches to Firefox and be OK with the way it's done - the Mozilla team might be interested in this problem on Windows also, since right now using the Windows HTTP stuff shares state with IE, but I'm guessing apps that rely on this get hosed when people use Firefox. So maybe Mozilla would like to provide an HTTP lib on Windows that shares state with Firefox, or something. No idea though. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
- it seems inevitable that both gnome-http-lib and Firefox would need to rely on some type of common repository of cookies, etc. and that this repo would be managed by some type of daemon that handled locking and change-notification; said daemon would need to be able to run sans Firefox, and would need to handle changes to the repo, not be read-only. Isnt there some work been done on using gnome-keyring to store authentication information for firefox? (sorry I cant remember the link to the patch in FF bugzilla). Wouldnt it be a natural extension to this to use either use this, or upcoming GSettings (gnome-y) or dconf (more cross desktoppy) for the cookie store. Both of these implementations already deal with locking and change notification, so why do we need a new daemon? (especialy if dconf AIUI is daemonless) - though it never pays to block on a committee, I would say key people to get sign off from (or at least keep informed) would be Alex so we know the solution works for gvfs, and the Mozilla team, so we know they will take the patches to Firefox and be OK with the way it's done Yeah, and lets not forget webkit also. I think this is where something like dconf, which sounds a bit less GNOME-y has a greater chance of being signed off by on multiple projects with stakeholders outside GNOME. I guess it would then be a natural extension to make libsoup / gvfs et. al depend on dconf for authentication info and cookies. But does this then fall down or come back the the same debate about hard and soft deps and where (how low) something in the stack like dconf, gnome-keyring and gvfs (authentication) lies. John - the Mozilla team might be interested in this problem on Windows also, since right now using the Windows HTTP stuff shares state with IE, but I'm guessing apps that rely on this get hosed when people use Firefox. So maybe Mozilla would like to provide an HTTP lib on Windows that shares state with Firefox, or something. No idea though. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote: That's all very interesting, but what about a better integration of on-line applications in the desktop environment like regular applications? Have you seen, for instance, prism? http://labs.mozilla.com/2007/10/prism/ I think this is a very simple idea, and also a good match for a on-line desktop project. I agree, and blogged about this last month: http://cgwalters.livejournal.com/9706.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Nov 22, 2007 6:40 AM, Alp Toker [EMAIL PROTECTED] wrote: Colin Walters wrote: On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote: That's all very interesting, but what about a better integration of on-line applications in the desktop environment like regular applications? Have you seen, for instance, prism? http://labs.mozilla.com/2007/10/prism/ I think this is a very simple idea, and also a good match for a on-line desktop project. I agree, and blogged about this last month: http://cgwalters.livejournal.com/9706.html There's no need to look far and wide for this kind of functionality. We've already got a sleek and powerful browser component built around GLib and GTK+ whose sole purpose is integration with the desktop: http://live.gnome.org/WebKitGtk Just to broaden this discussion a little I recently tried Pagico [1] (which is a cross platform personal organiser). AFAICT (its closed source) Their approach to cross platform development seemed to involve writing the application in PHP and then starting apache to serve it. The app is then a thin-ish wrapper around firefox/gtkmozembed widget that connected to http://localhost:port My question is, do we want to encourage this sort of development in GNOME, and if so, how?. For example, the new shiny HTML5 client db stuff in webkit [2] will go some way to allowing desktop apps to be written in HTML/JS and then run inside a light webkit shell, but can we do better. What about * A simple way to start a webkit browser widget associated with a private, standalone httpserver? - might be necessary if someone wants to write apps in PHP/some other server side language * Some way to communicate gtk-isms/function calls from the html/js app to the desktop. For example, I have previoulsy acomplished this (in pygtkmozembed) by 1) encoding gtk function calls as javascript status messages 2) catching on_status_changed and then reecreating the call Can webkit facilitate some sort of Gtk/GNOME javascript binding? Anyway, somthing else to think about John [1] http://www.pagico.com/ [2] http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/ http://live.gnome.org/WebKitGtk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Nov 21, 2007 3:40 PM, Alp Toker [EMAIL PROTECTED] wrote: Colin Walters wrote: On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote: That's all very interesting, but what about a better integration of on-line applications in the desktop environment like regular applications? Have you seen, for instance, prism? http://labs.mozilla.com/2007/10/prism/ I think this is a very simple idea, and also a good match for a on-line desktop project. I agree, and blogged about this last month: http://cgwalters.livejournal.com/9706.html Glad to know I am not the only one who thunk of that. :) There's no need to look far and wide for this kind of functionality. We've already got a sleek and powerful browser component built around GLib and GTK+ whose sole purpose is integration with the desktop: http://live.gnome.org/WebKitGtk Cool, will try it later. That's certainly something to look forward to. And I guess it would be nice and easy to improve Nautilus' Create Launcher... menu item behaviour by letting it create new links to RIAs directly onto the Desktop and GNOME Panel too... :) Pedro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
John Stowers wrote: For example, the new shiny HTML5 client db stuff in webkit [2] will go some way to allowing desktop apps to be written in HTML/JS and then run inside a light webkit shell, but can we do better. What about * A simple way to start a webkit browser widget associated with a private, standalone httpserver? - might be necessary if someone wants to write apps in PHP/some other server side language Hey John! Your ideas are on the right track but we do it a little differently in WebKit, mostly to the same effect. Our strategy with WebKit is to discourage traditional gtkmozembed hacks like embedding a web server in the process, in favour of providing direct access to the resource request/response layer and Document Object Model via GObject. Of course, you can still ship a web server with your product as a migration path if you want to deploy PHP applications. One of the entry points you might use to access the DOM, just to give you an idea of what I mean here: DOMCSSStyleDeclaration* webkit_page_get_style (WebKitPage *page); * Some way to communicate gtk-isms/function calls from the html/js app to the desktop. For example, I have previoulsy acomplished this (in pygtkmozembed) by 1) encoding gtk function calls as javascript status messages 2) catching on_status_changed and then reecreating the call Can webkit facilitate some sort of Gtk/GNOME javascript binding? We're just about to enable a complete C API to access the JavaScript engine, allowing calls into JS as well as the creation of completely new dynamic JS objects complete with custom callback handlers, which can be accessed directly from WebKitFrame, for example: JSGlobalContextRef webkit_frame_get_global_context (WebKitFrame *frame); I've created a proof of concept JavaScript D-Bus bridge using only this new C API so it's already quite powerful and expressive. I hope that WebKit will encourage application developers to actually move away from some of the practices you describe and back towards real GTK+ applications that use Web technologies as a complement, not a replacement, for our existing platform. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Nov 1, 2007 7:16 PM, John Stowers [EMAIL PROTECTED] wrote: On 11/2/07, Colin Walters [EMAIL PROTECTED] wrote: John Stowers wrote: But at the moment this particular 'PDA' requires a different way for it to be connected. As I explained earlier, the other 'PDA's we support are either connected(), disconnected(), or we ask for the user to connect them (log in) while we wait. I am interested in providing a consistant way for users to connect their 'PDA's (log in) and I do this by either using programmatic login (gdata for example), or asking them to log in using our simple browser login. online.gnome.org doesnt seem to support either of these scenarios, requiring a different connection procedure to everyone else. I am really interested in thinking about how to integrate sync into the desktop. So I'm planning to spend some time next week taking a look at how we can clean up some of the web service authentication in the desktop. Here's a wiki page with some initial thoughts: http://live.gnome.org/OnlineDesktop/WebAccountSystem Cool, sounds good. As I said, the site-specific-browser thing works quite well. For WebAccountSystem, when the user logs into something, you might want to consider doing that login with a small ssb - I find doing so differentiates the process and makes it more obvious to the user that their action results in a ssb being shown. Launching the system web browser to log in may result in 1) a new firefox tab 2) new firefox window 3) new/restore firefox session. The ssb thing seems more deterministic. You could make the ssb clearly Gnome Online Desktop Login branded. Once all the other things you mention are sorted out then you should have no problem propagating the login info from the ssb out to the system browser and the desktop. [snip] As Owen said, basically the way we'd thought login to online.gnome.org would work is that some part of your desktop (say the personalized application launcher) tells you you need to log in, and you click there to do so. I'm not sure at the moment what conduit would be syncing to/from online.gnome.org. Pretty much anything we currently sync through an intermediary and that is not a big binary file; * Application prefs (we have had our own settings/gconf sync for a while) * Tomboy notes * Contacts * Calendar info * Small files (/me ducks) That's all very interesting, but what about a better integration of on-line applications in the desktop environment like regular applications? Have you seen, for instance, prism? http://labs.mozilla.com/2007/10/prism/ I think this is a very simple idea, and also a good match for a on-line desktop project. Pedro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
John Stowers wrote: But at the moment this particular 'PDA' requires a different way for it to be connected. As I explained earlier, the other 'PDA's we support are either connected(), disconnected(), or we ask for the user to connect them (log in) while we wait. I am interested in providing a consistant way for users to connect their 'PDA's (log in) and I do this by either using programmatic login (gdata for example), or asking them to log in using our simple browser login. online.gnome.org doesnt seem to support either of these scenarios, requiring a different connection procedure to everyone else. I am really interested in thinking about how to integrate sync into the desktop. So I'm planning to spend some time next week taking a look at how we can clean up some of the web service authentication in the desktop. Here's a wiki page with some initial thoughts: http://live.gnome.org/OnlineDesktop/WebAccountSystem Obviously there's a lot more to add, but I'm hoping to create a system that other GNOME projects such as Conduit and Gimmie could make use of. Now, as for login to online.gnome.org itself; 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 web-login-driver could also be a client library I guess, but it does certainly provide the benefit of logging into a web service through the web, and having the desktop be able to pick it up. the final step in the process (rewriting the cookie file so the browser can pickup external logins) is not implemented. We can't really safely sync logins back to the browser right now. The point of web-login-driver is the other way around (web-desktop) as I mentioned above. As Owen said, basically the way we'd thought login to online.gnome.org would work is that some part of your desktop (say the personalized application launcher) tells you you need to log in, and you click there to do so. I'm not sure at the moment what conduit would be syncing to/from online.gnome.org. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On 11/2/07, Colin Walters [EMAIL PROTECTED] wrote: John Stowers wrote: But at the moment this particular 'PDA' requires a different way for it to be connected. As I explained earlier, the other 'PDA's we support are either connected(), disconnected(), or we ask for the user to connect them (log in) while we wait. I am interested in providing a consistant way for users to connect their 'PDA's (log in) and I do this by either using programmatic login (gdata for example), or asking them to log in using our simple browser login. online.gnome.org doesnt seem to support either of these scenarios, requiring a different connection procedure to everyone else. I am really interested in thinking about how to integrate sync into the desktop. So I'm planning to spend some time next week taking a look at how we can clean up some of the web service authentication in the desktop. Here's a wiki page with some initial thoughts: http://live.gnome.org/OnlineDesktop/WebAccountSystem Cool, sounds good. As I said, the site-specific-browser thing works quite well. For WebAccountSystem, when the user logs into something, you might want to consider doing that login with a small ssb - I find doing so differentiates the process and makes it more obvious to the user that their action results in a ssb being shown. Launching the system web browser to log in may result in 1) a new firefox tab 2) new firefox window 3) new/restore firefox session. The ssb thing seems more deterministic. You could make the ssb clearly Gnome Online Desktop Login branded. Once all the other things you mention are sorted out then you should have no problem propagating the login info from the ssb out to the system browser and the desktop. [snip] As Owen said, basically the way we'd thought login to online.gnome.org would work is that some part of your desktop (say the personalized application launcher) tells you you need to log in, and you click there to do so. I'm not sure at the moment what conduit would be syncing to/from online.gnome.org. Pretty much anything we currently sync through an intermediary and that is not a big binary file; * Application prefs (we have had our own settings/gconf sync for a while) * Tomboy notes * Contacts * Calendar info * Small files (/me ducks) John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
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
Re: Online Desktop and GNOME 2.22
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,
Re: Online Desktop and GNOME 2.22
Hiya, 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? OK. Let me explain what we have in conduit. We support lots of webservices in conduit, which means we have login code and experience for each one. As it turns out, most web login systems fall into two categories and require very little login logic. The two types of logins are; a) The ability to log in programatically. Call methodFoo(secretKey) on the server and get back a authentication frob to use in all subsequent calls b) Two step login. e.g. call methodLogin(user) on the server, which brings up a web browser, you log in then you call methodGetFrob(username) and you get your magic frob. Frob does not always equal a cookie IIRC. a) doesnt involve web-login-driver and/or ddm at all. Its not needed (beyond the 'what is my username on this service' type config we already discussed) My problem with the current implementation is that is doesnt reliably solve B in all cases. For example - we are concerned with the initial[1] login experience in conduit. Lets say you want to upload some photos to $WEBAPP from eye of gnome (i.e. you may treat Conduit as a DBus service - dont even start its gui). The first time the user ever does this they need to login to said $WEBAPP using a browser. If that is the case, it allows us a much cleaner [2] experiece if Conduit pops up a small site-specific-browser to allow the user to log in, rather than starting firefox which has its own problems, its hugeness, it not reliably getting the users attention, 26 other open tabs, session saver extension/restore previously crashed session, etc [3]). [1] The 'initial' experience actually happens quite a lot for some webservices - for example box.net logins only stay valid for a few hours. This means that you must re-login to the webservice almost every day. If this is the case it seems convoluted to go with the mugshot approach - switch to a browser, login, wait for it to pick up the cookie, get the cookie from mugshot, turn the cookie into a from that the box.net api needs (is this even possible in the general case?) [2] Their are some other hairy things here like there is no way to reliably start a new browsing session that blocks the caller (which is needed because many webservices invalidate the login if you call getFrob() before the user has logged in). So to come back to your question - I dont really want a seperate login dialog for online desktop (at least not as the final solution), I just would like online desktop to offer a login process that is more similar to all other $WEBAPPS and that allows a consistant login experience when authenticating, whether for the 0th, 1st, or nth time. And if we do have to authenticate then at least give us the option of not starting the whole system browser to do a simple 2 second login. Until something like a or b is possible Its a bit hard to make conduits round peg fit into online desktop square hole - especially when all other webservice login methods have roundish holes or holes of an oval nature. I know you think of online deskop as different, a always logged in type scenario, but that doesnt fit my use-case for it, and becomes even hairier when I cant get it to consistantly log in. I would really appreciate if you could check conduit out from SVN and play with how it logs into things using its built in web browser for and idea of what I mean [3]. [3] caveat: as I mentioned in my blog post, SVN head is a bit rocky atm. 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
Re: Online Desktop and GNOME 2.22
On Thu, 2007-11-01 at 09:20 +1300, John Stowers wrote: Hiya, 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? OK. Let me explain what we have in conduit. We support lots of webservices in conduit, which means we have login code and experience for each one. As it turns out, most web login systems fall into two categories and require very little login logic. The two types of logins are [ excellent detailed description omitted ] What if you don't think of online.gnome.org as a web service; what if you think of it like a PDA someone plugged into their USB port? - Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
[ excellent detailed description omitted ] What if you don't think of online.gnome.org as a web service; what if you think of it like a PDA someone plugged into their USB port? Excellent! Apologies if I mis/over-interpret your analogy but this is EXCATLY how I think about online.gnome.org Let me explain, because I think we have both build sufficiently large hammers so now everything looks like a nail. Here goes my nail story... Conduit already supports synchronization of many types of data (files, photos, contacts, calender, settings, notes, text) to many different kinds of 'PDAs'/$WEBAPPS. In this way I think of online.gnome.org as JUST ANOTHER 'PDA'[1] (dataprovider) that we want to support and we want to support it well. But at the moment this particular 'PDA' requires a different way for it to be connected. As I explained earlier, the other 'PDA's we support are either connected(), disconnected(), or we ask for the user to connect them (log in) while we wait. I am interested in providing a consistant way for users to connect their 'PDA's (log in) and I do this by either using programmatic login (gdata for example), or asking them to log in using our simple browser login. online.gnome.org doesnt seem to support either of these scenarios, requiring a different connection procedure to everyone else. I am really interested in thinking about how to integrate sync into the desktop. So now its your turn, what if you dont think of conduit as 'just another sync app' and start to think of it as 'the correct way to sync things to not just online.gnome.org but to other PDAs'. Regards John [1] If online.gnome.org gets wider acceptance then it might make sense for it to be the default 'PDA' for certain types of data, but thats a discussion for another day. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Le lundi 29 octobre 2007 à 17:43 -0400, Owen Taylor a écrit : This isn't a module proposal, but I wanted to start a conversation about how we can move the online desktop work closer to the GNOME release process and maybe get it lined up up for 2.24. While the response to the overall idea of the Online Desktop has been very positive, both at GUADEC and the Boston GNOME summit, we're pretty clearly not yet ready to be part of the overall GNOME 2.22 release. Some of the reasons: the code is in a lot of flux, and we don't have noticeable numbers of users beyond the developers; there are a number potentially controversial aspects such as our use of hippo-canvas and the presence of the Bigboard sidebar; we're not ready on server side for hundreds of thousands or millions of users. But I think there might be room for a preview release of the Online Desktop coinciding with 2.22. To me that, would involve: - Migrate everything feasible to gnome.org subversion - Starting installing our tarball releases on ftp.gnome.org - Announcing a set of packages that has been tested on top of GNOME 2.22 at the same time as GNOME 2.22. I don't think we'd follow the freeze schedule for 2.22; extended freezes just don't make sense at the current level of development. Our current set of modules is: * hippo-canvas: GUI library used inside the Mugshot client and Bigboard sidebar. Has certain properties that make it really nice to work with, and certain gaping holes. Just an internal dependency, not a platform library. * mugshot: This module really has three separate things in it libddm: C client library and core code for the desktop data model data-model-engine: Central daemon that connects to online.gnome.org and provides the data model to the desktop over D-BUS mugshot: client application for mugshot.org; not conceptually part of the online desktop. Splitting this module apart is a short-term goal of ours and is blocking moving stuff into GNOME subversion. * online-desktop: Another grab bag. Contains: Python bindings for libddm online-prefs-sync-daemon: syncs your GConf settings to online.gnome.org Scripts for logging into an online-desktop configured session * bigboard: the prominent UI component of the online-desktop. An extensible sidebar featuring local data (such as your recently used files), data retrieved via the Data Model (such as your contact list), and data retrieved directly from web services. * local-export-daemon: A minor component that exports information basic information about you to your local network via Avahi. None of these have extensive dependencies beyond the the GNOME platform; libcurl, sqllite3 and loudmouth are the only ones that occur to me at the moment. Hmm, is libcurl really needed ? We are already have libsoup for HTTP and SOAP request and gnome-vfs is pulling libneon. I wish we wouldn't need to put another http/ftp library in the GNOME desktop :( -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Frederic Crozat wrote: Hmm, is libcurl really needed ? libcurl is conceptually a dependency in the online desktop application layer (specifically a panel applet). Longer term though we should probably replace the usage of curl here with python. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote: Frederic Crozat wrote: Hmm, is libcurl really needed ? libcurl is conceptually a dependency in the online desktop application layer (specifically a panel applet). Longer term though we should probably replace the usage of curl here with python. What about using one of the already existing dependencies like libsoup or gnome-vfs? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Hi, Hubert Figuiere wrote: On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote: Frederic Crozat wrote: Hmm, is libcurl really needed ? libcurl is conceptually a dependency in the online desktop application layer (specifically a panel applet). Longer term though we should probably replace the usage of curl here with python. What about using one of the already existing dependencies like libsoup or gnome-vfs? Any http lib would be pretty trivial to swap in if the Mugshot app were proposed for GNOME, but for now I would not worry about it. HTTP is mostly used by the Mugshot app, not the other components. (Remember that right now there's one mugshot binary that includes both data-model-engine and mugshot stacker, but that isn't the long-term plan. We are splitting off Mugshot so it's just the one feed of stuff people are doing on various web sites, shown in a tray icon feature, and optional just as using any other site or app would be. online desktop is intended to be a separate thing from mugshot) I do think libsoup, gnome-vfs, neon, and curl are all bad answers long-term for apps that want to use web APIs or download an icon. The right answer will address among other things how to share cookies and proxy settings and cache with the browser. And IMO should just be HTTP, not SOAP or DAV. So this is a good problem for someone to try to solve. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote: Frederic Crozat wrote: Hmm, is libcurl really needed ? libcurl is conceptually a dependency in the online desktop application layer (specifically a panel applet). Longer term though we should probably replace the usage of curl here with python. Would we really want a potentially core part of the desktop to be implemented in Python? :-( ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Hi, Philip Withnall wrote: Would we really want a potentially core part of the desktop to be implemented in Python? :-( Colin is talking about the mugshot stacker app, not the parts that would be potentially core. (Though, I do think python is questionable for tray icons and daemons, since for whatever reason each python / pygtk process is so huge. An under-mentioned reason why we keep writing stuff in C is the multiple-process architecture of a GNOME/KDE style desktop, vs. the one-big-process approach of say Eclipse that makes per-runtime overhead less relevant. But this is pretty much a tangent.) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Tue, 2007-10-30 at 21:02 +, Philip Withnall wrote: On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote: Frederic Crozat wrote: Hmm, is libcurl really needed ? libcurl is conceptually a dependency in the online desktop application layer (specifically a panel applet). Longer term though we should probably replace the usage of curl here with python. Would we really want a potentially core part of the desktop to be implemented in Python? :-( well platform is C in Gnome and I would hope there will be a lib other apps can use to benefit from all the cool new stuff coming from the online desktop. (the UI frontend or applet can remain in python of course but the interface to the online world should be C if possible) jamie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Hi, jamie wrote: (the UI frontend or applet can remain in python of course but the interface to the online world should be C if possible) And it is. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Ter, 2007-10-30 at 17:10 -0400, Havoc Pennington wrote: (Though, I do think python is questionable for tray icons and daemons, since for whatever reason each python / pygtk process is so huge. Well, last I checked, the cpython implementation *never* releases memory back to the OS. This is why I can't really understand why so many things in gnome are done in python. I mean, check your rhythmbox before and after you load a python plugin. I really like python's philosophy and syntax but this memory use behavior continues to drive me away from it and from apps written in it. Anyway, yea, this is quite a tangent here. Rui signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Tue, 2007-10-30 at 21:02 +, Philip Withnall wrote: Would we really want a potentially core part of the desktop to be implemented in Python? :-( Can we please stop wasting everybody's time with I-don't-like-your-choice-of-language discussions? Fix the resource consumption issues if you care, but don't try to stop others from doing productive work. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Rui Tiago Cação Matos wrote: On Ter, 2007-10-30 at 17:10 -0400, Havoc Pennington wrote: (Though, I do think python is questionable for tray icons and daemons, since for whatever reason each python / pygtk process is so huge. Well, last I checked, the cpython implementation *never* releases memory back to the OS. This is why I can't really understand why so many things in gnome are done in python. I mean, check your rhythmbox before and after you load a python plugin. I really like python's philosophy and syntax but this memory use behavior continues to drive me away from it and from apps written in it. Anyway, yea, this is quite a tangent here. This changed in Python 2.5 which is now widely distributed. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
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
