[Sugar-devel] Plan for HTML activities services

[Daniel Narvaez]

Hello,

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.

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.

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:

1 Add a websocket server to the toolkit Activity class. HTML services will
send messages to it to interact with datastore and presence service.
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.
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.
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.
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.

Thoughts about this would be very welcome.

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.

-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130428/cc47e9a6/attachment.html>