[Sugar-devel] native HTML activity

[Daniel Narvaez]

On Thursday, 7 November 2013, NoiseEHC wrote:

> Hi!
>
> Just to prove that it can be done, I have hacked a little bit more on the
> native HTML activity which can be found here:
> https://github.com/NoiseEHC/sugar-webkit-native
>
> I tried to create virtual pages by using WebKit1's or Soap's url rewriting
> callbacks but it turns out that no matter what you do, the thing wants to
> use the data from the TCP stream... So I turned to starting a (Soap) HTTP
> server inside the native activity (on a random port) and it works. Now the
> activity runs from localhost (/activity and /web subfolders) and there is a
> virtual folder called /journal. It has only one hacked file, the
> /journal/journal.html, which has links to all the things in the journal. It
> queries the journal service via DBUS. I have to tell you that working with
> GVariant from C is a real PITA, so I did not implement the load/store of
> the real journal files, but it is clearly possible... (Beware, it leaks
> every possible resources, it is just a proof of concept.)
>

Can you explain more in detail what you have in mind with journal? I won't
ask you to complete the prototype given your bad experience with GVariant :)


> Now, I do not know what is the problem with WebKit1, it seems to work for
> me, and at least it does not crash on an XO-1.75 as WebKit2 does. On the
> other hand I cannot try it on my XO-1.75 as it is not possible anymore to
> install webkitgtk-devel on the machine as I told you last time...
>
> This whole project has the following benefits:
> - It is much-much faster than the python one. It does matter on an XO.


What is faster exactly? I can imagine startup time, anything else?

I had proposed to write the web activity stub in C given memory and
startup performance gains. Not everyone was favourable. I think it would be
fine if we can keep it really simple. It's somewhat worrying that you
already run into annoyances with GVariant... Not many regular Sugar
contributors are familiar with C (maybe I'm the only these days). The risk
is that it will become a piece of code no one is able or wants to hack on.


> - It does not depend on the WebKitGTK python bindings to be maintained, it
> can use all WebKitGTK's features.


I don't see that as a real advantage. With gobject introspection bindings
are mostly automatic and, as far I know, the whole C api is already covered.


> - It does not have a dependency on Node.js.


Neither the current code does. Node is used for developer tools only, it's
not running inside sugar or activities.


> - It does not use WebSocket, which would require using WebKit2...
>

Why would WebSocket require WebKit2? WebKit1 and WebKit2 are basically two
different APIs for the same rendering engine (with 1 being deprecated).

That said, I will probably be the happiest if we can implement the whole
API without the WebSocket server, but we need to prove that's possible.
Let's figure out a plan for Journal first, then we can look into the
smaller bits.

Thanks!



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