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

[Gonzalo Odiard]

In a related note, I was working on use websockets in JournalShare activity.
I used tornado, because I needed a web server anyway.
More information after the tests.

Gonzalo


On Thu, Apr 25, 2013 at 6:59 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> 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
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130426/a96303c5/attachment.html>