<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 28, 2013 at 8:49 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><div><div><div><div><div><div>Hello,<br><br></div>I looked a bit more into refactoring the presence stuff in toolkit so that it could be run in the shell process for html activities. The big problem is that it's very strictly tied to Activity, which contains UI stuff we don't want for this case. It is an issue for the gtk3 code itself which is pretty messy as a result of this. Furthermore the absence of any unit testing makes refactoring very high risk, especially in a piece of code which is known to be fragile.<br> <br></div></div></div></div></div></div></div></blockquote><div><br></div><div style>+1</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><div><div><div><div><div></div>Though I still think we want HTML activities to interact directly with a communication channel inside the shell, rather than having to go through the activity. It doesn't really make sense to have thick python backend behind an HTML activity. If nothing else it has huge memory costs, that I described in another email.<br> <br></div></div></div></div></div></div></blockquote><div><br></div><div style>I do not agree here. It's true a python WebActivity have a cost in memory, but the value is this much easier to hack. This is a important value, for us and for our users. </div> <div style><br></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><div><div></div>So I came up with a plan to get there gradually, trying to minimize the amount of wasted work but also of disruption to the existing gtk3 toolkit. Here it is:<br> <br></div>1 Add a websocket server to the toolkit Activity class. HTML services will send messages to it to interact with datastore and presence service.<br></div></div></div></div></blockquote><div><br></div><div style>I suppose we will have a WebActivity class and the websocket will be added only to that, right? </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><div><div> </div>2 Create new Datastore and Collaboration classes in toolkit. To speed up implementation, initially they will be allowed to make use of code which is in Activity or tied to it (like PresenceService). Though the API should be kept as free as possible from links with that code and should instead more or less mirror what we need from Javascript. The websocket server will use these classes to fullfill the html layer requests.<br> </div></div></div></blockquote><div><br></div><div style>We already have a datastore module in the toolkit. What should be the change? </div><div style>About Collaboration, I would like to know more about the history. We had that, and was removed. And the changes were really disruptive and we have bugs without solve yet. </div> <div style> <br></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>3 Gradually reimplement Datastore and Collaboration to free them from the links with UI code. Add full unit testing as we do that. I expect quite a bit of code duplication to happen at this stage, we don't want to refactor too much yet, to avoid breaking gtk3.<br> </div><div>4 As soon the links with UI are broken, we can just push down the websocket service to the shell. The service classes will stay in toolkit and be imported by the websocket code. This is so that they can be also used in-process by the gtk3 toolkit.<br> </div></div></blockquote><div><br></div><div style>I don't think the code have too much links with the UI...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr">5 Rework gtk3 Activity to use these new services implementation and drop the old ones. It might be a good chance to cleanup the API if we will still care about the gtk3 toolkit.<br clear="all"><div><div><div> <div><div> <div><div><div><div><br></div><div>Thoughts about this would be very welcome.<br><br>If we agree on the plan, I will start from 1, which should be pretty easy now that we have a glib based websocket server.<span class="HOEnZb"><font color="#888888"><br> </font></span></div><span class="HOEnZb"><font color="#888888"><div> <br></div></font></span></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div style>Gonzalo</div><div><br></div><div><br></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><div><div><div><div><div><div><div><span class="HOEnZb"><font color="#888888"><div>-- <br>Daniel Narvaez<br> </div></font></span></div></div></div></div></div></div></div></div></div> <br>_______________________________________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br> <br></blockquote></div><br></div></div>