<div dir="ltr">On 29 April 2013 14:07, Gonzalo Odiard <span dir="ltr"><<a href="mailto:gonzalo@laptop.org" target="_blank">gonzalo@laptop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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. </div></blockquote><div><br></div>
<div>While this is true for a gtk3 activity I don't see why it would be the case for html.<br><br>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.<br>
<br></div><div>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.<br></div><div><br></div><div>Anyway I don't think > 30 MB for a basically empty html activity is acceptable. And we didn't even look at startup time. <br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div></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></div></div></div></blockquote><div><br></div></div><div>
I suppose we will have a WebActivity class and the websocket will be added only to that, right? </div><div class="im">
<div></div></div></div></div></div></blockquote><div><br></div><div>Yes.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>
</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></div></div></blockquote><div><br></div></div><div>We already have a datastore module in the toolkit. What should be the change? </div></div></div></div></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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. <br>
</div><div class="im">
</div></div></div></div></blockquote><div><br></div><div>We had something a bit different. It was a separate service to which both shell and activity was talking.<br><br>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.<br>
</div><div><br></div><div>Introducing bugs in already fragile code is exactly the reason I'm proposing to get there gradually.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>
</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></div></blockquote><div><br></div></div><div>I don't think the code have too much links with the UI...</div><div class="im"><div> <br></div></div></div></div></div></blockquote><div><br></div><div>For example PresenceService uses Activity which is the main UI class... <br>
</div></div></div></div>