Michael Catanzaro <[email protected]> writes: > On Tue, 2014-10-14 at 14:44 -0400, Matthias Clasen wrote: >> On Tue, Oct 14, 2014 at 1:47 PM, Jim Nelson <[email protected]> wrote: >> >> > It would be great if the DOM was available via WebKitGTK and the local >> > library did the IPC for us, but I've been told that that's not going >> > to happen. The DOM is a huge API and I can't blame them for that. I >> > do wish the separate process model was an optional run mode because, >> > as I said, I don't see a lot of benefits moving to it for Geary. >> > >> >> Michael and Robert were sticking their heads together this weekend to >> see if there is a good way forward for geary's needs. Maybe they can >> share the results. > > The easiest way forward would be new WebKit API to allow access to the > DOM from the UI process, via a proxy object that automatically routes > messages between the UI and web processes. I have no doubt there are > good reasons why this API doesn't exist -- probably performance, for > one. Carlos?
Yes, there are actually several problems with that approach. Forwarding every single DOM method/event to the UI process would mean a lot of IPC traffic, which for sure will affect performance. But more importantly, the DOM API is synchronous, so all of those messages would be blocking both the web and UI processes. The idea is that you can move the logic that needs to access the DOM to the web extension, and then you only communicate to the UI process when needed with the results. That's what we do in epiphany, for example, to implement all the features that require access to DOM. > Anyway, Robert and I spent yesterday morning learning how to get a very > simple example of UI process <-> web extension IPC working via D-Bus. > (Well, mostly working: Robert discovered today that our example D-Bus > signal is broken....) The plan was for him to publish the code on GitHub > soon. The approach is similar to Epiphany's, but Vala's excellent D-Bus > support should allow Geary to avoid a lot of the glue code used in > Epiphany. I won't have time to work more on it for the foreseeable > future, unfortunately. The current epiphany code was supposed to be a temporary solution, the idea was to use a private dbus connection instead of using the session bus, but in the end we never found the time to do that. > I think Geary is really the worst-case scenario here: a fairly large > application that performs significant DOM manipulations in response to > UI events, already written with the WebKit1 API. For apps that are just > displaying web pages (everything not geary?) with no such compatibility > concerns, porting should be relatively easy. Evolution is even worse scenario, I would say, but at least is written in C :-) > Happy October, > > Michael > _______________________________________________ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
pgpS_mdbBFnLT.pgp
Description: PGP signature
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
