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