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

[lionel at olpc-france.org]

Hi Daniel,

Cool. Nice start.
Just to be sure to understand:
- Is it specific to WebKit2?
- Is to replace the console-message?
- Is to replace telepathy?

	Lionel.


------------------------------

Message: 3
Date: Thu, 25 Apr 2013 23:59:40 +0200
From: Daniel Narvaez <dwnarvaez at gmail.com>
To: "sugar-devel at lists.sugarlabs.org"
	<sugar-devel at lists.sugarlabs.org>
Subject: [Sugar-devel] Prototype python <-> js IPC
Message-ID:
	<CANTHhvZVA=EeiJtGLftBjZvSrtx3qR8Nk8PCoOBkNoJ4nRyE3A at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

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

sugar-toolkit-gtk3 patch

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

hello-world patch

https://github.com/dnarvaez/hello-world/commit/d102639bd43a99904d431210028a1
ede66237427

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