<div dir="ltr">On 16 February 2014 20:43, Emil Dudev <span dir="ltr"><<a href="mailto:emildudev@gmail.com" target="_blank">emildudev@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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><div><div><div><div><div><div><div><div><div><div><div>Hello,<br><br>It's been a long time...<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote><div><br></div><div>Hi Emil!<br></div><div> </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><div><div>
<div><div><div><div><div><div><div><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></div>
</div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>As you might have seen in another thread, we are trying to get the sugar-web bits of Sugarizer merged back into upstream sugar-web. I don't know the status of Lionel effort on collaboration, but I think he is not looking into integration with the current framework. The stuff you are pointing out below is exactly what we need to figure out for that integration to happen!<br>
</div><div> </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><div><div><div><div><div><div><div><div><div></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" target="_blank">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></div></div></div></div></div></div></div></blockquote><div><br></div><div>Can you explain why the shell needs to know about shared activities? I'm thinking the activity could register those activities with the server and the shell get them from the server together with activities shared by other users.<br>
</div><div><br></div><div>If we really need the shell to know I think we should add a property to the existing activity dbus service. <br></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><div><div><div><div><div><div>
</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).</div></div></div>
</div></div></div></div></blockquote><div><br></div><div>Is that BuddyModel contact_id maybe? I would suggest to handle the deduplication in a second step by the way, not really important for a first prototype.<br></div><div>
</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><div><div><div> 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></div></div></div></div></div></div></blockquote><div><br></div><div>Is this all inside neighborhood.py?<br></div><div><br></div><div>From a quick look to it, what I'd suggest is to rename Neighborhood -> TelepathyNeighborhood, ActivityModel -> TelepathyActivityModel, BuddyModel -> TelepathyBuddyModel. Then write WebsocketNeighborhood, WebsocketBuddyModel, WebsocketActivityModel with exactly the same public interface. Finally write a new ActivityModel which just merges WebsocketNeighborhood and TelepathyNeighborhood (it should not be hard, it looks like a list of activities/buddies with signals for changes).<br>
</div><div><br></div><div>Are there abstraction leaks that makes that impossible or problematic?<br></div></div></div></div>