<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Em seg, 17 de out de 2016 às 04:31, Carlos Garcia Campos <<a href="mailto:cgarcia@igalia.com">cgarcia@igalia.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El lun, 10-10-2016 a las 01:19 +0000, <a href="mailto:tevaum@gmail.com" class="gmail_msg" target="_blank">tevaum@gmail.com</a> escribió:<br class="gmail_msg">
> Hello, everyone.<br class="gmail_msg">
<br class="gmail_msg">
Hi, <br class="gmail_msg">
<br class="gmail_msg">
> Some background first: my name is Estêvão and every now and the I try<br class="gmail_msg">
> to contribute to Gnome Web, AKA Epiphany. First time was back in<br class="gmail_msg">
> 2010. After the migration of Epiphany to WebKit, it stopped<br class="gmail_msg">
> identifying feed links on pages. I had to dig into JavaScriptCore to<br class="gmail_msg">
> call JavaScript functions to check for feed links on pages. DOM<br class="gmail_msg">
> bindings were only in TODO by then. Now what I need to do is a little<br class="gmail_msg">
> bit different, but also involves JavaScriptCore. We need to bridge<br class="gmail_msg">
> between JavaScript and C code so that an about page can be able to<br class="gmail_msg">
> list URLs to display. I was chocked that up to now JavaScriptCore is<br class="gmail_msg">
> untouched. So I started thinking about how could a GObject binding to<br class="gmail_msg">
> JSC be implemented.<br class="gmail_msg">
><br class="gmail_msg">
> The proposal:<br class="gmail_msg">
><br class="gmail_msg">
> I'm thinking about creating GObjects to warap JSC objects. For<br class="gmail_msg">
> instance: GJSCContext wrapping JSContextRef, GJSCObject wrapping<br class="gmail_msg">
> JSObjectRef and so on.<br class="gmail_msg">
<br class="gmail_msg">
We talked during the web engines hackfest about adding a GLib wrapper<br class="gmail_msg">
for JSC, not necessarily a 1 to 1 wrapper from JSC object to GLib<br class="gmail_msg">
objects, though.<br class="gmail_msg">
<br class="gmail_msg">
> I implemented a POC of the API and a simple client to make my<br class="gmail_msg">
> intentions clearer. It's available on <a href="https://github.com/tevaum/jsc-" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/tevaum/jsc-</a><br class="gmail_msg">
> bindings.<br class="gmail_msg">
<br class="gmail_msg">
Thanks for working on this!<br class="gmail_msg">
<br class="gmail_msg">
> With that *not-so-gobject* partial API the client is able to bridge<br class="gmail_msg">
> javascript functions to native C callbacks and to execute javascript<br class="gmail_msg">
> code from C. Also the C function returns an array to the javascript<br class="gmail_msg">
> code. An example of error handling is also shown.<br class="gmail_msg">
<br class="gmail_msg">
I think error handling is a bit different in this case, we probably<br class="gmail_msg">
need a special way to handle JS exceptions.<br class="gmail_msg">
<br class="gmail_msg">
> I think that we have to start simple and add stuff incrementally,<br class="gmail_msg">
> based on what's already being used/requested by people. Please take<br class="gmail_msg">
> your time to dig into the example code provided, ask questions and<br class="gmail_msg">
> poit directions, so that we can buld a better WebKitGTK+.<br class="gmail_msg">
<br class="gmail_msg">
I agree with the idea of starting simple and going step by step, but<br class="gmail_msg">
before designing a new API there are a set of general things we should<br class="gmail_msg">
decide, and the most important thing, we should know what we want this<br class="gmail_msg">
new API to be used for. I think the API should allow:<br class="gmail_msg">
<br class="gmail_msg">
* Easily run javascript snippets from C code in a web extension.<br class="gmail_msg">
* Interact with javascript contexts, retrieve existing JS values in<br class="gmail_msg">
the context to the C code, and add values from C to the javascript<br class="gmail_msg">
context.<br class="gmail_msg">
* Easily expose full objects to javascript<br class="gmail_msg">
<br class="gmail_msg">
That would cover the main uses cases, replacing the dom bindings and<br class="gmail_msg">
injecting custom code to JavaScript. <br class="gmail_msg">
<br class="gmail_msg">
Regarding the general things we should decide:<br class="gmail_msg">
<br class="gmail_msg">
* Naming: we don't need a name for the library because it will be part<br class="gmail_msg">
of libjavascriptcoregtk (gtk is for gtk port, not because it uses gtk<br class="gmail_msg">
at all), but we need to use apublic header and a common prefix for<br class="gmail_msg">
methods and types. In your POC you are using javascript.h as the header<br class="gmail_msg">
name, jscore prefix for methods and GJSC for types. The API should be<br class="gmail_msg">
consistent in this regard.<br class="gmail_msg">
<br class="gmail_msg">
</blockquote><div><br></div><div>Yes, I really messed up the namespaces :P What about using javascriptcoregtk.h for the header, JSCoreStuff for the objects and jscore_stuff for the methods? Or maybe jsc-gtk.h JSCStuff for the objects and jsc_stuff for the methods?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * Memory management: this is very important to decide how to declare<br class="gmail_msg">
your objects, they could be GObject, boxed types with ref counting,<br class="gmail_msg">
etc. Note that javascript objects are garbage collected, so it's very<br class="gmail_msg">
important to have mechanisms, to prevent wrapped object from being<br class="gmail_msg">
destroyed by the garbage collector if we still have a wrapper alive.<br class="gmail_msg">
So, we will probably have to protect all js object when wrapped, which<br class="gmail_msg">
means API use will always have to manually unref every single wrapper.<br class="gmail_msg">
We might want to make it easier by making out wrappers initially<br class="gmail_msg">
unowned, for example. There might be cases in which we want to wrapper<br class="gmail_msg">
to be automatically destroyed when the wrapped object is garbage<br class="gmail_msg">
collected too. We need to take into account all these cases when<br class="gmail_msg">
designing the API.<br class="gmail_msg">
</blockquote><div><br></div><div> I think that boxed types are the best, because we can ref-count them but don't get the overhead of gobject inheritance, remembering it's just a wrapper...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * Error handling: I'm not sure GError is enough to handle js<br class="gmail_msg">
exceptions. They can happen at any time and have additional information<br class="gmail_msg">
like line number, column, etc. that can't be represented by GError. The<br class="gmail_msg">
Objc API allows to set a callback per context to handle the exceptions.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>We can use a boxed type here too (simpler) or subclass GError to add the details... </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would start the API with the wrappers needed to setup a js context<br class="gmail_msg">
and then the JSValueRef wrapper with methods to set an retrieve simple<br class="gmail_msg">
values (string, bool, number, array, object/dictionary, date), leaving<br class="gmail_msg">
the handling of custom objects out for now. We could probably use a bug<br class="gmail_msg">
report or a dedicated thread in this list to decide about this specific<br class="gmail_msg">
part of the API (whether we want to expose it as a single Value type or<br class="gmail_msg">
have a different type per value type, whether to use GObjects or boxed<br class="gmail_msg">
types, whether to make it initially unowned, etc.)<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div><br></div><div>I'll wait for your comments on the namespace and types to open that bug report. This way, I can upload the initial patch.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we can start adding the API to the source code without enabling<br class="gmail_msg">
it in production builds, nor installing the headers until it reaches a<br class="gmail_msg">
mature enough state. As with the GTK+ public APIs, the whole API should<br class="gmail_msg">
be covered by unit tests and all patches adding/modifying the public<br class="gmail_msg">
API should include a unit test.<br class="gmail_msg"></blockquote><div><br></div><div>Agree with that. By the way, where will we put the new files? in Source/JavascriptCore somewhere or in a subfolder inside Source/WebKit2/WebProcess/InjectedBundle/API? Also I would appreciate if you point me some example unit tests and API documentation.</div><div> </div><div>Thank you for your time reviewing my proposal :]</div><div><br></div><div><br></div><div>Estêvão Samuel Procópio Amaral</div><div><br></div></div></div>