Re: [Sugar-devel] Prototype python - js IPC
Hello, as I posted in a separate thread I wrote a simple websocket server using GIO, which should take no additional memory. Next step, I'm going to try to make the presence service stuff for html activities run inside the shell. I'm hoping I could just import it without moving the code out of toolkit. If I can prove that's doable without too much refactoring, I will then post a patch to run the websockets server in the shell and we can start implementing apis with it! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
On 04/25/2013 11:59 PM, Daniel Narvaez 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. You will need to get twisted and autobahn, on Fedora this means: # yum install python-twisted # easy_install autobahn Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
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 dwnarv...@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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
So, lot of options here and not enough time to try all of them out. Though... I'm leaning towards having a websocket server in the sugar shell. Having system apis implemented in a separate process make sense from a security point of view. It also seems to be the same architecture as Firefox OS, https://wiki.mozilla.org/images/thumb/e/e2/B2G-processes.png/650px-B2G-processes.png I'm a bit worried about having to adapt the toolkit presence code to this model because it's fragile already but my gut feeling is that it's worth the pain. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
That option would also help a lot with memory too. A MiniBrowser (C code only) running manuq's clock takes ~10 mb per process. An activity (using exec=sugar-html-activity) running the same takes 30 mb. I think that's not acceptable, we would have to go the multiple-activities-per-process route which introduces interesting problems. First of all with the current WebKit implementation the content of multiple activities will be in the same process. Multiple content processes are on the roadmap but there isn't even a bug for it yet, as far as I can tell. On 26 April 2013 15:12, Daniel Narvaez dwnarv...@gmail.com wrote: So, lot of options here and not enough time to try all of them out. Though... I'm leaning towards having a websocket server in the sugar shell. Having system apis implemented in a separate process make sense from a security point of view. It also seems to be the same architecture as Firefox OS, https://wiki.mozilla.org/images/thumb/e/e2/B2G-processes.png/650px-B2G-processes.png I'm a bit worried about having to adapt the toolkit presence code to this model because it's fragile already but my gut feeling is that it's worth the pain. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
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 dwnarv...@gmail.com To: sugar-devel@lists.sugarlabs.org sugar-devel@lists.sugarlabs.org Subject: [Sugar-devel] Prototype python - js IPC Message-ID: CANTHhvZVA=eeijtglftbjzvsrtx3qr8nk8pcoobknoj4nry...@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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
On 26 April 2013 21:13, lio...@olpc-france.org wrote: Hi Daniel, Cool. Nice start. Just to be sure to understand: - Is it specific to WebKit2? Actually it might work on WebKit1. - Is to replace the console-message? Yes - Is to replace telepathy? Not exactly. But well, we would use this to talk to telepathy too. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Prototype python - js IPC
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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
On Thu, Apr 25, 2013 at 3:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I wrote a quick prototype for a possible python - js IPC. I am missing some background here. In what cases do we need such IPC? The two cases that spring to mind are journal and collaboration. I think in an ideal world the javascript code would communicate directly with system services. I agree. To me, gobject-introspectionis the obvious choice here, and it can be used from javascript (in some form at least). How hard would it be to make it available here? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
On 26 April 2013 00:54, Daniel Drake d...@laptop.org wrote: On Thu, Apr 25, 2013 at 3:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I wrote a quick prototype for a possible python - js IPC. I am missing some background here. In what cases do we need such IPC? The two cases that spring to mind are journal and collaboration. Those are the two main cases I have in mind. There might also be smaller stuff like being able to get the xo color setting. I think in an ideal world the javascript code would communicate directly with system services. I agree. To me, gobject-introspectionis the obvious choice here, and it can be used from javascript (in some form at least). How hard would it be to make it available here? Using an extension, it might be possible to run a seed context ( https://live.gnome.org/Seed) inside the web content process and then have the web context communicate with it through postMessage. Chrome is doing something similar with extensions/context scripts. I'm not sure how well exchanging binary streams would work with that approach (it's going to be important both for datastore and collaboration). In theory, since they use the same javascript interpreter, using seed it might even be possible to give access to gobject-introspection (or part of it) directly from the web context. Though that starts to feel messy. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
On 26 April 2013 02:36, Daniel Narvaez dwnarv...@gmail.com wrote: Using an extension, it might be possible to run a seed context ( https://live.gnome.org/Seed) inside the web content process and then have the web context communicate with it through postMessage. Chrome is doing something similar with extensions/context scripts. I'm not sure how well exchanging binary streams would work with that approach (it's going to be important both for datastore and collaboration). About binary streams, there is very likely a way to do it efficiently. ArrayBuffers for example looks like they might be helpful. In theory, since they use the same javascript interpreter, using seed it might even be possible to give access to gobject-introspection (or part of it) directly from the web context. Though that starts to feel messy. This is not possible using seed public API at least. Understandably they don't expose the js core context anywhere. All in all I'm getting to like seed-context-inside-web-process idea. Might be worth trying it out. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
On 26 April 2013 03:01, Daniel Narvaez dwnarv...@gmail.com wrote: All in all I'm getting to like seed-context-inside-web-process idea. Might be worth trying it out. Actually why not a python context inside the web process? That would allow to reuse the presence service toolkit code, which I don't really want to rewrite. Sounds almost perfect... I must be missing something, /me goes to sleep :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
