<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>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>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>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>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>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.<br></div><div>
<br>-- <br>Daniel Narvaez<br>
</div></div></div></div></div></div></div></div></div></div>