<div dir="ltr"><div><div><div>Hello,<br><br></div>I wrote a quick prototype for a possible python <-> js IPC.<br><br></div>sugar-toolkit-gtk3 patch<br><br><a href="https://github.com/dnarvaez/sugar-toolkit-gtk3/commit/5ba4e19732b4eec688dd73be8408c0d8e6a91299">https://github.com/dnarvaez/sugar-toolkit-gtk3/commit/5ba4e19732b4eec688dd73be8408c0d8e6a91299</a><br>
<br></div>hello-world patch<br><div><br><a href="https://github.com/dnarvaez/hello-world/commit/d102639bd43a99904d431210028a1ede66237427">https://github.com/dnarvaez/hello-world/commit/d102639bd43a99904d431210028a1ede66237427</a><br>
<br></div><div>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:<br><br></div><div>* 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.<br clear="all">
</div><div><div><div><div>* This is communicating with the activity.<br>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.<br>
</div><div>* 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.<br>
</div><div>* I have not picked a secondary protocol yet, autobahn implements WAMP for example. It shouldn't be hard anyway and easy to change.<br></div><div>* 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!<br>
</div><div>* I'm not sure finding a free port by trial and error is fine. Maybe the shell should manage a pool of ports.<br></div><div>* This is all private to Sugar-on-linux. It should be wrapped inside the javascript API.<br>
</div><div>* 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.<br></div><div><br>-- <br>Daniel Narvaez<br>
</div></div></div></div></div>