[Sugar-devel] Prototype python <-> js IPC

Daniel Narvaez dwnarvaez at gmail.com
Thu Apr 25 17:59:40 EDT 2013


I wrote a quick prototype for a possible python <-> js IPC.

sugar-toolkit-gtk3 patch


hello-world patch


You need the latest sugar-build if you want to give it a try. Though having
a look at the code would be useful as well, it's pretty simple. Some notes:

* It is based on websockets. I should note that we need some kind of IPC in
any case because in WebKit2 and in "modern" browsers in general, the
process where javascript is running and the UI process are separate.
* This is communicating with the activity.
I think in an ideal world the javascript code would communicate directly
with system services. Though we have a lot of code which runs inside
Activity to implement telepathy-based collaboration and we would have to
rewrite it in javascript or somehow expose it as a service on dbus, which
is going to make things even more fragile then they are already (it would
be return of sugar-presence-service, sort of). I tend to think
communicating with the activity process is a good compromise for now. The
only way to avoid proxying through another process and talk directly to
telepathy would be to implement dbus bindings in a WebKit extension, which
I think at the moment would be too much work.
* I'm not too convinced about introducing a dependency on twisted (I
haven't measured memory usage/startup time though). It should not be too
hard to write a basic GSocket based websocket server, we can look at the
gtk broadway code for inspiration.
* I have not picked a secondary protocol yet, autobahn implements WAMP for
example. It shouldn't be hard anyway and easy to change.
* The websocket server should authenticate the clients. WAMP would make
that easy. The python code would generate a token and pass it to the
start() call. The token would then be used to authenticate clients. In
general, I need help thinking through the security implications here, not
an expert!
* I'm not sure finding a free port by trial and error is fine. Maybe the
shell should manage a pool of ports.
* This is all private to Sugar-on-linux. It should be wrapped inside the
javascript API.
* I don't know much about websockets performance. If anyone does please
speak up :) At least they support binary transfers which we will need for

Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130425/601d0f09/attachment.html>

More information about the Sugar-devel mailing list