<div dir="ltr"><div>Very interesting! Couple of initial questions, trying to understand better:<br><br></div><div>* Why did you go with a separate web activity instead on integrating directly in the shell?<br></div><div>* Would it be possible to implement this without adding to apisocket and thus making it sugar specific?<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 January 2014 00:09, Emil Dudev <span dir="ltr"><<a href="mailto:emildudev@gmail.com" target="_blank">emildudev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Please don't look at the poor javascript code :(<br><br></div><div>I created a web activity that can act as sugar's mesh for web activities (with a few lines of code it should work for normal activities, too).<br>
<br></div>This time I went the other way around. Instead of sending invites, when an activity is shared, everyone on the mesh can join it (it was easier to implement). Normal invites could also be implemented, I just have to work on integrating it with sugar's frame (for the invite notification).<br>
<br></div>Since this 'new mesh' is a web activity, it can be opened with a normal desktop browser. Yet it will have little to no functionality. The simplest explanation: the mesh can not know the path of an activity to open. With a little work, this problem can be solved.<br>
<br></div>For the past 2 days I went deep into TogetherJS and I no longer believe that it will suit sugar's needs.<br></div>The first reason is a WebKit bug. I noticed that when a CSS transform property is used, the screen will go blank (gray). I manually edited TogetherJS' jQuery modifications to not include CSS transforms, yet this bug still happens. I have not yet found the problem. Although this is a WebKit bug (it does not happen outside of sugar), it is one of the reasons to drop TogetherJS.<br>
</div>The second one is the communication protocol. Although it is quite easy (the server just replies the messages to all clients and lets them handle everything), the protocol isn't much secure and may cause more traffic than needed. I don't expect a kid to look at the code and 'hack' the protocol, yet I still don't like the idea of leaving everything to the clients.<br>
</div><div>An other reason, although not much of a problem and more a feature, is the fact that TogetherJS syncs every single mouse move, mouse click, form change, input field update... These are lots of unneeded stuff.<br>
</div><div><br></div>As it was discussed earlier, a low-level API can work fine for sugar and it won't be hard to create such an API. The thing that will be lost (and hard to implement) are the many neat high-level features of TogetherJS.<br>
<div><div><div><div><div><div><div><div><div><br></div><div>About what I made and how to test it:<br></div><div>The sugar-net web activity is the 'mesh'. And a nice activity to test with is the modified gtd-activity.<br>
</div><div>Once the sugar-net activity is started, it will communicate with a WebMesh class in apisocket.py.<br></div><div>When a web activity (like gtd-activity) is shared, it will appear as a shared activity when you hover the mouse over the XO icon in the sugar-net activity.<br>
</div><div>When you click on it from an other mesh activity (an other instance of sugar), it will automatically start the web activity (gtd-activity) and the shared session will begin between the two.<br><br></div><div>Both sugar-net and gtd-activity still use Mozilla's hub server for the communication.<br>
<br></div><div>sugar-toolkit-gtk3: <a href="https://github.com/edudev/sugar-toolkit-gtk3/tree/webcollaboration" target="_blank">https://github.com/edudev/sugar-toolkit-gtk3/tree/webcollaboration</a><br></div><div>sugar: <a href="https://github.com/edudev/sugar/tree/webcollaboration" target="_blank">https://github.com/edudev/sugar/tree/webcollaboration</a><br>
</div><div>gtd-activity: <a href="https://github.com/edudev/gtd-activity/tree/collaboration" target="_blank">https://github.com/edudev/gtd-activity/tree/collaboration</a><br></div><div>sugar-net: <a href="https://github.com/edudev/sugar-net" target="_blank">https://github.com/edudev/sugar-net</a><span class="HOEnZb"><font color="#888888"><br>
<br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Emil Dudev<br></div><div><br></div></font></span></div></div></div></div></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Jan 18, 2014 at 4:20 PM, Emil Dudev <span dir="ltr"><<a href="mailto:emildudev@gmail.com" target="_blank">emildudev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>I'm not quite sure.<br><br></div>One way to do it is to use 1 class as the client and integrate the class into the current mesh box (neighbourhood.py). This would probably mean that normal sugar activities could use this 'new protocol'.<br>
</div>An other way would be to use a web activity as the client. I'm not sure how exactly will I have to handle the activity -> sugar communication and pass the invites.<br><br></div>If going with the second approach I'd have to rewrite the whole neighbourhood view in HTML/javascript. And with this an other question arises: How much of sugar's core can be rewritten in HTML/javascript.<br>
</div>One of TogetherJS's features is to follow your friends around pages. I think it's limited to a single domain, but I believe I can use it.<br><br></div>I believe that the first approach would be easier, but with all this talk about new frameworks for web activities and going multi platform, I'll choose the second approach.<span><font color="#888888"><br>
<br></font></span></div><span><font color="#888888">Emil Dudev<br><div><div><div><div><br></div></div></div></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Jan 18, 2014 at 1:19 PM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Interesting! Are you planning to use a js actitvity or a python one as client?<br></div><div class="gmail_extra">
<div><div><br><br><div class="gmail_quote">On 18 January 2014 01:21, Emil Dudev <span dir="ltr"><<a href="mailto:emildudev@gmail.com" target="_blank">emildudev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Busy month...<br><br></div>Anyway, I checked out telepathy and tried to fix the many protocol problems. Sadly, I gave up pretty easily. I suppose it would be easier to rewrite the whole process from scratch.<br>
<br></div>Today I was able to recreate the basic functionality of TogetherJS' server. From a nodejs server, I rewrote it in python (using gwebsockets). This will give me the ability to customize it freely.<br><br></div>
Tomorrow I plan on building the basic invitation process using web sockets. I suppose it will be more reliable than telepathy. And it would possibly be better for an Android app or other systems with limited functionality.<br>
<br></div>About WebRTC: I really think that peer-to-peer connections are needed. But at this point, I'll go with client-server connections.<br><div><br>gwebsockets: <a href="https://github.com/edudev/gwebsockets/tree/master" target="_blank">https://github.com/edudev/gwebsockets/tree/master</a><br>
websocket-server: <a href="https://github.com/edudev/web-reply" target="_blank">https://github.com/edudev/web-reply</a><span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>
Emil Dudev<br></div></font></span><div><div><div><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">
On Sun, Jan 12, 2014 at 8:51 PM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div>On 12 January 2014 19:01, Emil Dudev <span dir="ltr"><<a href="mailto:emildudev@gmail.com" target="_blank">emildudev@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div>About the telepathy part to send only the invites and establish the connection:<br></div>I can't seem to be able to complete the invitation accepted process. Sometimes it works, sometimes not (mostly not). For normal sugar activities it's the same (with the exception that with them it mostly works, at least I think it works).<br>
</div><div>Exchanging the TogetherJS ID is not a problem. The invited user can't seem to connect to the telepathy channel properly.<br></div>As you noted above, it's a protocol mess.<br></div><div>If telepathy is completely dropped for web activities, then a question arises: how to send the invite with the unique ID?<br>
</div></div></blockquote><div><br></div></div><div>I don't know the details of the current invitation protocol. I suppose you could register a "private" activity with the server and then send a token to the invitee. Making this up as an example, not really well thought :)<br>
</div><div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Also, I still don't like using 1 server and having everything else depend on that 1 server. The server would most likely have to process a lot of traffic.<br>
Would it be possible to use a peer to peer connection with web sockets? Browsers don't support this, with reason. But if sugar's core is used, it should be possible.<span><font color="#888888"></font></span></div>
</div></blockquote><div><br></div></div><div>Did you investigate WebRTC? If nothing else I suspect it would allow to exchange data between peers. I'm not sure if it provides any facility that we could use to share presence information, i.e. a shared buddies+activiities list. That's the really hard problem to solve if you want fully p2p communication.<br>
</div></div></div></div>
</blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br>Daniel Narvaez<br>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Daniel Narvaez<br>
</div>