[Sugar-devel] Plan for HTML activities services

[Daniel Narvaez]

On 29 April 2013 14:07, Gonzalo Odiard <gonzalo at laptop.org> wrote:

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

While this is true for a gtk3 activity I don't see why it would be the case
for html.

sugar-html-activity is going to be really simple as soon as the refactoring
I'm proposing is completed. It will basically just create a WebView and
load a url in it. Pretty much what we have right now in WebActivity
(without inheriting all the Activity stuff). The rest of the code will all
stay python, and hence as hackable, even if it will be in a different
module.

The problem isn't really much python but all the stuff we import in each
Activity process. Needlessly, because we need to use IPC from javascript in
any case.

Anyway I don't think > 30 MB for a basically empty html activity is
acceptable. And we didn't even look at startup time.

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

Yes.


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

We need to figure out the javascript API, then I'll post a proposed
interface. I suspect it will be a bit higher level than the wrapper we have
currently but I haven't looked at datastore much yet.


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

We had something a bit different. It was a separate service to which both
shell and activity was talking.

I read the feature proposal and in my opinion none of the reason that made
us choose this direction are valid in the new html activity context.

Introducing bugs in already fragile code is exactly the reason I'm
proposing to get there gradually.


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

For example PresenceService uses Activity which is the main UI class...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130429/397703b1/attachment.html>