<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello,<br><br>It's been a long time...<br></div>To be honest, I haven't worked much on this.<br></div>I've been following the Sugarizer project and I'm not exactly sure how sugar web collaboration will continue.<br>
<br></div>Anyway, when I last tested some things 2 weeks ago regarding telepathy and tried to setup a parallel websocket protocol for collaboration, I stumbled upon some difficulties. Today I managed to fix some things in my code and I'm hoping to get a second opinion.<br>
<br></div>As mentioned above, I've tried to set up a websocket protocol for activity collaboration (including non-web activities and the mesh box/neighborhood view). Sadly, I'm having difficulties with sugar's code, as there isn't a good abstraction layer and telepathy is somewhat <a href="http://everywhere.in">everywhere.in</a> the code.<br>
</div>What I've currently managed is to just display the users in the neighborhood view. I have yet to add support for invites in this new protocol.<br></div>The problems I have are:<br></div>1. from sugar's core I can only know which activities are currently running, while I need a list of only the shared activities (and their share scope). Telepathy does this by having it's code both in sugar's core and in sugar's toolkit.<br>
</div>2. In order for the two protocols to run parallel and to not have duplicates on the meshbox, I'd need some sort of telepathy contact ID and a buddy key (I have no idea where to get these from). Also, telepathy room handles and buddy handles seem to be passed around between instances of different types (this is what I meant by 'telepathy is everywhere in the code').<br>
<br></div>I've tried to leave many comments in my code and there I've documented more problems. Yet the above 2 are somewhat major and I'm not sure how to handle them.<br><br></div>Here is my code:<br></div><div>
Changes to gwebsockets, so it can have client functionality: <a href="https://github.com/edudev/gwebsockets/">https://github.com/edudev/gwebsockets/</a><br></div>A web client that mirror's TogetherJS's server (it just replies the messages): <a href="https://github.com/edudev/web-reply">https://github.com/edudev/web-reply</a><br>
</div>Sugar (only neighborhood.py is important): <a href="https://github.com/edudev/sugar/tree/webcollaborationframework">https://github.com/edudev/sugar/tree/webcollaborationframework</a><br><br></div>Cheers,<br></div>Emil Dudev<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 1:07 AM, 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"><div class="">On 20 January 2014 22:22, 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 class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Mon, Jan 20, 2014 at 10:33 PM, Daniel <span>Narvaez</span> <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank"><span>dwnarvaez</span>@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>On 20 January 2014 13:53, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Mon, Jan 20, 2014 at 12:48 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"><div></div><div>* Why did you go with a separate web activity instead on integrating directly in the shell?<br>
</div></div></blockquote></div><div>Integrating it directly with the current neighborhood?<br></div></div></div></div></blockquote><div><br></div></div><div>Not necessarily, I was also wondering why you didn't write the same thing in python inside the shell. But now I probably see, an activity was the only sensible place to put it if you wasn't merging with the telepathy view.<br>
</div></div></div></div></blockquote><div><br></div></div><div>I've got some plans rotating in my head to rebuild sugar entirely as a desktop web app. It's subjective. I'll try to not think 'big'. When I have some free time I'll work on integrating it with the current neighborhood.<br>
</div></div></div></div></blockquote><div><br></div></div><div>sugar-web started from an experiment with a full rewrite of Sugar based on the Firefox OS backend. I find thinking 'big' to be a very useful way to generate ideas, then come back to the boring realities of backward compatibility and such :)<br>
</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>One problem would be of duplicates if a user is both on the telepathy neighborhood and this 'new' one.<br>
</div><div>
As mentioned in the earlier messages, I was thinking of writing a python class that would act as the client between the sugar's mesh and the web socket server.<br></div><div>I wasn't sure how exactly to handle regular activities and web activities in such a 'merged' neighborhood.<br>
</div><div><div></div></div></div></div></div></blockquote><div><br></div></div><div>I'm not sure to understand where we would get duplicates. It seems like the mesh view is a list of activities. The new framework will provide you another list. Isn't it just matter of merging the two? Even in the current view if the user is in two activities, I believe we show it two times. (Might very well be missing something!).<br>
</div></div></div></div></blockquote><div><br></div></div><div>As mentioned in the earlier messages, I was never able to get collaboration between normal activities to work, so probably I'm missing something.<br></div>
<div>
>From what I was able to get working with telepathy is that on the network view (without the user doing/sharing anything), I can see all the users in 'the neighborhood' (on the same jabber server). I see their <span>XO</span> icons. These icons could be duplicated, as there would be an icon from the jabber server and an icon from the web socket server for the same user.<br>
</div></div></div></div></blockquote><div><br></div></div><div>Yes, I had forgot about XO icons which are not inside an activity. We could probably deduplicate those by keeping the telepathy id in the XO metadata for the new framework.<br>
</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div>Besides the <span>XO</span> icons on the network view, I've heard rumors (and/or seen pictures) of having shared activities next to a user's icon, having <span>adhoc</span>/<span>wifi</span> networks on the view, having other things on the view.<br>
</div></div></div></div></blockquote><div><br></div></div><div>I think it's more likely activity icons with Xo icons grouped around them.<br></div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div>What I've done with the sugar-net activity is to place all the users on a random position and when the mouse hovers the user's icon a list with that user's shared activities will show. Clicking on an item from the list will join the activity.<br>
</div><div>I've went for a similar, but slightly different approach. Who can I ask for the proper behavior of the network view? When I'll be merging the two, it would be good to know what to aim for. I'll probably not be able to test all the features (e.g. <span>wifi</span>/<span>adhoc</span> networks).<br>
</div></div></div></div></blockquote><div><br></div></div><div>I would try with a separate email about that subject. Walter, Manuel, Gonzalo probably knows more then me about that. Problem is that I think most of the people that had some experience with the collab stuff are not involved anymore. Ultimately you might have to read the UI code and guess from there :)<br>
</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The reason I want to figure out if it's possible to merge the views is that we are not going to be able to drop telepathy based collaboration any time soon. We will have first to prove that the new framework works better and get activity authors to buy into it, then deprecate, finally wait a few years for activities to be migrated. So we need a plan on how the two can coexist. I'm afraid having two separate views it's not something we can afford user experience wise... but it would be good to hear the design team opinions on this.<br>
</div></div></div></div></blockquote><div><br></div></div><div>Right. Life would be a lot easier if you didn't have to worry about backward compatibility and deprecation policies.<br></div><div>I haven't given much thought to telepathy and normal activities. It won't happen again, I'll think of them first, before I do something collaboration related. <br>
</div></div></div></div></blockquote><div><br></div></div><div>Ignoring backward compatibility is often good when you are doing the initial research on something important like the collaboration framework, so don't let me bring you back to boring realities too soon :)<br>
</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div></div><div>* Would it be possible to implement this without adding to apisocket and thus making it sugar specific?<br>
</div></div></blockquote></div>Making web collaboration sugar specific, or not (being able to collaborate from a normal browser)?<br></div><div class="gmail_quote">Since apisocket.py is the only way to communicate between the javascript code and sugar, I'd say it won't be easy.<br>
</div><div class="gmail_quote">As noted above, it won't be very easy to have collaboration outside of sugar, because the browser does not know where the activity page lies (if it needs to join/open an activity).<br></div>
<div class="gmail_quote">It is possible to join a web activity, without changes to apisocket.py. The problem would be that the current webkit page (sugar-net activity) would be overwritten by the new activity (the one that is joined). There's no problem from the web activity's point of view. The problem is that sugar would still think that this is the sugar-net activity, and I'm not sure what that would lead to. An other problem is that the sugar-net activity is lost (it's page was reloaded into the joined activity).<br>
</div><div class="gmail_quote">A possible way to solve this is to open the new activity's page into a separate tab. But then there are other problems: sugar would think the sugar-net activity and it's new tab (the new activity) are one. Also, I'm not sure how tab handling would look in webkit, without the top navigation bars.<br>
</div></div></div></blockquote><div><br></div></div><div>Yeah, some sugar specific bits will be necessary to launch the activity. It seems like it would be good to keep those bits as minimal as possible.<br></div><div>
<div></div></div></div></div></div></blockquote><div><br></div></div><div>When the network view's are merged, launching an activity should be handled without javascript. Actually the only thing that would be needed in <span>apisocket</span>.<span>py</span> would be to let sugar know when the sharing has started and when it has ended. Can't think of anything else, other than letting sugar 'force' a web activity into sharing itself.<br>
</div></div></div></div></blockquote><div><br></div></div><div>Could the shell know directly from the server when an activity has started/ended rather than going through apisocket?<br></div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">The questions don't seem to have simple answers...<br></div><div class="gmail_quote">When I'm writing the code, I'm not sure which way to go. I don't believe that I can decide what is best for sugar. It would be nice to know what the community is thinking and what is their vision of how web collaboration should be handled.<span></span></div>
</div></div></blockquote><div><br></div></div><div>Yes. I think we are all a bit unsure about the way we should go. The research you are doing is extremely valuable because it's bringing us closer to figure that out... Lionel and Suraj has been experimenting with collaboration too, so it would be very interesting to hear their feedback.<br>
</div></div></div></div>
</blockquote></div></div><br>I'm glad that I can help sugar with it's evolution. At the same time I'm able to learn a lot about the many technologies out there in the world. I just hope I'm not doing things too slow.<span><font color="#888888"><br>
</font></span></div></div></blockquote><div><br></div></div><div>Hehehe, I've been pretty shocked by the speed you GCI guys has been doing things, I had an hard time to keep up, so definitely don't worry about that :)<br>
</div></div>
</div></div>
</blockquote></div><br></div>