<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Em seg, 17 de out de 2016 às 14:24, 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, 17-10-2016 a las 12:37 +0000, <a href="mailto:tevaum@gmail.com" class="gmail_msg" target="_blank">tevaum@gmail.com</a> escribió:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Em seg, 17 de out de 2016 às 04:31, Carlos Garcia Campos <cgarcia@iga<br class="gmail_msg">
> <a href="http://lia.com" rel="noreferrer" class="gmail_msg" target="_blank">lia.com</a>> escreveu:<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > little<br class="gmail_msg">
> > > bit different, but also involves JavaScriptCore. We need to<br class="gmail_msg">
> > bridge<br class="gmail_msg">
> > > between JavaScript and C code so that an about page can be able<br class="gmail_msg">
> > to<br class="gmail_msg">
> > > list URLs to display. I was chocked that up to now JavaScriptCore<br class="gmail_msg">
> > is<br class="gmail_msg">
> > > untouched. So I started thinking about how could a GObject<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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/j" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/tevaum/j</a><br class="gmail_msg">
> > sc-<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<br class="gmail_msg">
> > bridge<br class="gmail_msg">
> > > javascript functions to native C callbacks and to execute<br class="gmail_msg">
> > javascript<br class="gmail_msg">
> > > code from C. Also the C function returns an array to the<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > take<br class="gmail_msg">
> > > your time to dig into the example code provided, ask questions<br class="gmail_msg">
> > 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,<br class="gmail_msg">
> > but<br class="gmail_msg">
> > before designing a new API there are a set of general things we<br class="gmail_msg">
> > should<br class="gmail_msg">
> > decide, and the most important thing, we should know what we want<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > part<br class="gmail_msg">
> > of libjavascriptcoregtk (gtk is for gtk port, not because it uses<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > header<br class="gmail_msg">
> > name, jscore prefix for methods and GJSC for types. The API should<br class="gmail_msg">
> > be<br class="gmail_msg">
> > consistent in this regard.<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
><br class="gmail_msg">
> Yes, I really messed up the namespaces :P What about using<br class="gmail_msg">
> javascriptcoregtk.h for the header, JSCoreStuff for the objects and<br class="gmail_msg">
> jscore_stuff for the methods? Or maybe jsc-gtk.h JSCStuff for the<br class="gmail_msg">
> objects and jsc_stuff for the methods?<br class="gmail_msg">
<br class="gmail_msg">
We don't use gtk in any of our public headers, so maybe <jsc/jsc.h>,<br class="gmail_msg">
JSCFoo, jsc_foo. What do other people think?<br class="gmail_msg">
<br class="gmail_msg">
> > * Memory management: this is very important to decide how to<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > alive.<br class="gmail_msg">
> > So, we will probably have to protect all js object when wrapped,<br class="gmail_msg">
> > which<br class="gmail_msg">
> > means API use will always have to manually unref every single<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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">
> ><br class="gmail_msg">
><br class="gmail_msg">
> I think that boxed types are the best, because we can ref-count them<br class="gmail_msg">
> but don't get the overhead of gobject inheritance, remembering it's<br class="gmail_msg">
> just a wrapper...<br class="gmail_msg">
<br class="gmail_msg">
It doesn't need to be just a wrapper, because to wrap the JSC API you<br class="gmail_msg">
can just use the existing API. As I said, this depends on how we design<br class="gmail_msg">
the value object for example, if we use a different subtype for every<br class="gmail_msg">
value type, we definitely want to use GObjects. I really don't think<br class="gmail_msg">
there's that much overhead in using GObject, compared to boxed types.<br class="gmail_msg">
And it also depends on whether we want to use floating references,<br class="gmail_msg">
especially for the JSCValue it could be interesting to make it<br class="gmail_msg">
initially unowned.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div><br></div><div>Well... I don't really see a point on having subtypes for every kind of value... maybe code maintainability, but I don't think this will be hurt if we use only one type for values (yet). Feel free to convince me though. And it's a good idea to make JSCValues initially unowned.</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<br class="gmail_msg">
> > information<br class="gmail_msg">
> > like line number, column, etc. that can't be represented by GError.<br class="gmail_msg">
> > The<br class="gmail_msg">
> > Objc API allows to set a callback per context to handle the<br class="gmail_msg">
> > exceptions.<br class="gmail_msg">
> ><br class="gmail_msg">
><br class="gmail_msg">
> We can use a boxed type here too (simpler) or subclass GError to add<br class="gmail_msg">
> the details... <br class="gmail_msg">
<br class="gmail_msg">
I wouldn't use GError, but a custom exception object (boxed type or<br class="gmail_msg">
whatever), because it's not that we want extra info, but that maybe we<br class="gmail_msg">
don't really need the error code and quark.<br class="gmail_msg">
<br class="gmail_msg">
> > I would start the API with the wrappers needed to setup a js<br class="gmail_msg">
> > context<br class="gmail_msg">
> > and then the JSValueRef wrapper with methods to set an retrieve<br class="gmail_msg">
> > simple<br class="gmail_msg">
> > values (string, bool, number, array, object/dictionary, date),<br class="gmail_msg">
> > leaving<br class="gmail_msg">
> > the handling of custom objects out for now. We could probably use a<br class="gmail_msg">
> > bug<br class="gmail_msg">
> > report or a dedicated thread in this list to decide about this<br class="gmail_msg">
> > specific<br class="gmail_msg">
> > part of the API (whether we want to expose it as a single Value<br class="gmail_msg">
> > type or<br class="gmail_msg">
> > have a different type per value type, whether to use GObjects or<br class="gmail_msg">
> > boxed<br class="gmail_msg">
> > types, whether to make it initially unowned, etc.)<br class="gmail_msg">
> ><br class="gmail_msg">
><br class="gmail_msg">
> I'll wait for your comments on the namespace and types to open that<br class="gmail_msg">
> bug report. This way, I can upload the initial patch.<br class="gmail_msg">
<br class="gmail_msg">
Ok, note that it's not just me, for public API in WebKitGTK+ we hace a<br class="gmail_msg">
rule that it needs to be approved by two reviewers, so maybe you want<br class="gmail_msg">
to wait ot hear the opinion of other people. Also, I would at least<br class="gmail_msg">
send a proposal here with the types you are going to add and propotypes<br class="gmail_msg">
of methods before spending too much time with the actual<br class="gmail_msg">
implementation, just in case.<br class="gmail_msg"></blockquote><div><br></div><div>So, considering your previous comments, w<span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">e can do something like this for a start:</span></div></div><div class="gmail_quote"><div><br></div><div>Objects:</div><div>o JSCContext</div><div>o JSCValue<br></div><div>o JSCObject</div><div> * JSCError (JSCArray, JSCDate and other stuff should come here too)</div><div><br></div><div>Methods:</div><div>JSCContext* jsc_context_new();</div><div>JSCObject* jsc_context_get_global_object(JSCContext*);</div><div>JSCValue* jsc_context_evaluate_script(JSCContext *, gchar* script, JSCError* err);</div><div>JSCValue* jsc_value_new_string(JSCContext*, gchar *value);<br></div><div>JSCValue* jsc_value_new_boolean(JSCContext*, gboolean value);</div><div>JSCValue* jsc_value_new_number(JSCContext*, double value);</div><div>gboolean jsc_value_is_string(JSCValue*);<br></div><div>gboolean jsc_value_is_boolean(JSCValue*);<br></div><div>gboolean jsc_value_is_number(JSCValue*);<br></div><div>gboolean jsc_value_is_object(JSCValue*); //or maybe jsc_object_new_from_value</div><div>gchar* jsc_value_get_string(JSCValue*);<br></div><div>gboolean jsc_value_get_boolean(JSCValue*);<br></div><div>gdouble jsc_value_get_number(JSCValue*);<br></div><div>JSCObject* jsc_value_get_object(JSCValue*); //or maybe jsc_object_new_from_value</div><div>JSCObject* jsc_object_new(JSContext*);</div><div>gboolean jsc_object_has_property(JSCObject*, gchar* property_name);</div><div>JSCValue* jsc_object_get_property(JSCObject*, gchar* property_name);</div><div>void jsc_object_set_property(JSCObject*, gchar *property_name, JSCValue* property_value);<br></div><div>gboolean jsc_object_delete_property(JSCObject*, gchar* property_name);<br></div><div><br></div><div>Implementing this API will let the client execute javascript, retrieve values returned from it, create new values and inject them as global object (window) properties. Is this enough for a start? Gratton and others, which kind of stuff do you need to do with JSC?</div><div><br></div><div>One think is a little fuzzy for me. It's </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<br class="gmail_msg">
> > enabling<br class="gmail_msg">
> > it in production builds, nor installing the headers until it<br class="gmail_msg">
> > reaches a<br class="gmail_msg">
> > mature enough state. As with the GTK+ public APIs, the whole API<br class="gmail_msg">
> > should<br class="gmail_msg">
> > be covered by unit tests and all patches adding/modifying the<br class="gmail_msg">
> > public<br class="gmail_msg">
> > API should include a unit test.<br class="gmail_msg">
><br class="gmail_msg">
> Agree with that. By the way, where will we put the new files? in<br class="gmail_msg">
> Source/JavascriptCore somewhere or in a subfolder inside<br class="gmail_msg">
> Source/WebKit2/WebProcess/InjectedBundle/API?<br class="gmail_msg">
<br class="gmail_msg">
This will be used by WebKit injected bundles, but it's an independent<br class="gmail_msg">
API that could be used by building only jsc. The API should be in<br class="gmail_msg">
Source/JavascriptCore/API/glib and the tests could be added to<br class="gmail_msg">
Source/JavaScriptCore/API/tests/glib or<br class="gmail_msg">
Tools/TestWebKitAPI/Tests/JavaScriptCore/glib.<br class="gmail_msg">
<br class="gmail_msg">
> Also I would appreciate if you point me some example unit tests and<br class="gmail_msg">
> API documentation.<br class="gmail_msg">
<br class="gmail_msg">
All our tests are in Tools/TestWebKitAPI, see the gtk directories. We<br class="gmail_msg">
could use a similar infrastructure based on gtester for JSC.<br class="gmail_msg">
<br class="gmail_msg">
For more general rules take a look at:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://webkit.org/getting-started/#contribute" rel="noreferrer" class="gmail_msg" target="_blank">https://webkit.org/getting-started/#contribute</a><br class="gmail_msg">
<a href="http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API" rel="noreferrer" class="gmail_msg" target="_blank">http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API</a><br class="gmail_msg">
<br class="gmail_msg">
We will use mostly the same rules of the WebKit2 API for the JSC one.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>Thanks for this info. I'll check them all :]</div><div><br></div></div></div>