<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 9:43 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 class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>The thing I'm facing is that there is telepathy 'magic' code both in sugar's core and sugar's toolkit (per activity/process). I writing 'magic', because I don't understand it, and I have tried.<br> </div><div><div>If sugar's core is responsible entirely for the meshbox, it should know which of the user's currently running activities are shared, so it can announce it.<br></div>If I make the activity responsible for itself with the server (regarding the meshbox), it would mean that each activity will open an extra connection to the server. Which is something I want to avoid. Instead, my plans were to have 1 connection to the server - a class in sugar's core, with the needed interface.<br> </div><div><div>From my understanding of telepathy, even though each activity has it's own client, there is one connection (I might be wrong here).<br></div>An activity would either way have 1 connection to the server (which will be for activity related stuff). If an activity opens an extra connection to the server (the one for the mesh box), the problem will be that it would need info from sugar's shell.<br> </div><div><br>One thing that might be a good idea, is to change the server. As mentioned several times, the server currently just replies messages between clients. This leaves the clients to handle the protocol, but it mostly causes extra bandwidth - a client will definitely receive a message multiple times, just because an other client has asked for it. By making the protocol a bit more complex to the server side, I should be able to find an optimal solution.<br> <br></div><div>Using dbus to share information is a good idea, but it's something I try to avoid.<br>What if a web activity is shared. Web activities don't have a dbus service, but a simple one can be added. Still... all the code is in javascript. That javascript has to notify apisocket, and it should notify the service, which should notify the shell, which will notify the client. That's chain is a bit long. Not that I haven't already implemented more than half it in my early attempts, and of course deleted the code and thought of something better (at least I'm hoping it's better).<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 class="gmail_extra"><div class="gmail_quote"><div></div><div class=""><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><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></div></blockquote><div><br></div><div>Yes, that is the buddy's contact_id. Solving duplicates in an other step will save me a lot of time (at least now).<br></div><div>I'm either thinking for zero backward compatibility or I'm thinking too much for the future.<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 class="gmail_extra"><div class="gmail_quote"><div></div><div class=""> <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><div>Is this all inside neighborhood.py?<br></div></div></div></div></blockquote><div><br></div><div>Sadly, no. Different telepathy handles are passed around neighborhood.py, buddy*.py, invite*.py (and I'm not sure where else). In my opinion, classes which should not know anything about telepathy, have such things are member variables. Yet, I can't say that I have much experience, so I'm probably wrong.<br> <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 class="gmail_extra"><div class="gmail_quote"><div></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></blockquote><div><br></div><div>I'm not exactly sure about the number of such changes, that have to be done. But it should be possible.<br> </div><div>My concern is that the number of classes to change will be... not little (although the changes should be small and easy, with most classes).<br><br></div><div>Emil Dudev<br></div></div></div></div>