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

[Daniel Narvaez]

Hello,

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

sugar-toolkit-gtk3 patch

https://github.com/dnarvaez/sugar-toolkit-gtk3/commit/5ba4e19732b4eec688dd73be8408c0d8e6a91299

hello-world patch

https://github.com/dnarvaez/hello-world/commit/d102639bd43a99904d431210028a1ede66237427

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
collab.

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