[Sugar-devel] Plan for HTML activities services

[Manuel Quiñones]

Hi,

2013/4/28 Daniel Narvaez <dwnarvaez at gmail.com>:
> 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:

Yes I think your plan makes sense and goes for the right direction of
cleaning the APIs.  It is cumbersome to have the gtk UI stuff getting
memory for html activities, which don't need it.

I also wished Sugar had unit tests to make refactoring safer, so I
agree here too, it is good to write them in the go.

Great to see you already started with step 1 :)

> 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
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



--
.. manuq ..