[Sugar-devel] Plan for HTML activities services

[Gonzalo Odiard]

On Sun, Apr 28, 2013 at 8:49 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> 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.
>
>
+1


> 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.
>
>
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.

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.
>

I suppose we will have a WebActivity class and the websocket will be added
only to that, right?


> 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.
>

We already have a datastore module in the toolkit. What should be the
change?
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.


> 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.
>

I don't think the code have too much links with the UI...


> 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.
>
>
Gonzalo




> --
> Daniel Narvaez
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130429/c10c34ef/attachment-0001.html>