[Webkit-unassigned] [Bug 188742] [GLIB] Expose JavaScriptCore options in GLib public API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188742

--- Comment #4 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Adrian Perez from comment #3)
> (In reply to Carlos Garcia Campos from comment #2)
> > (In reply to Adrian Perez from comment #1)
> > > (In reply to Carlos Garcia Campos from comment #0)
> > > > I think it would be useful to expose the JSC options in the API. Right now
> > > > it's possible to change them using the env vars, but it would be better to
> > > > provide some API. To ensure API/ABI stability we could use a common
> > > > interface to set the options, that receive the option string identifier and
> > > > the value, similar to the GtkPrintSettings API, for example. Main problem is
> > > > that users don't know the options available, so we could provide names for
> > > > the most important options, like we do in WebKit2 API with editing commands.
> > > > We could also include API to get information about the options available
> > > > (name, value type, default value and description). Applications could use
> > > > that to create command line options to set them, for example.
> > > > 
> > > > JSCOptions* jsc_options_get (void); // Get the singleton instance
> > > > gboolean jsc_options_set_string (JSCOptions* options, const char* option,
> > > > const char* value);
> > > > char* jsc_options_get_string (JSCOptions* options, const char* option);
> > > > gboolean jsc_options_set_int (JSCOptions* options, const char* option, gint
> > > > value);
> > > > int jsc_options_get_int (JSCOptions* options, const char* option);
> > > > ......
> > > > typedef gboolean (* JSCOptionsFunc) (JSCOptions* options, const char*
> > > > option, GType type, GValue* default_value, const char* description, gpointer
> > > > user_data);
> > > > void jsc_options_foreach (JSCOptions* options, JSCOptionsFunc function,
> > > > gpointer user_data);
> > > 
> > > This being like this, it is like a mini-object system, so I wonder whether it
> > > would make more sense to make JSCSettings a class which inherits from GObject
> > > and make each option a property instead:
> > > 
> > >  * jsc_options_get_{string,int,bool,…} → g_object_get
> > >  * jsc_options_set_{string,int,bool,…} → g_object_set
> > >  * jsc_options_foreach → g_object_class_list_properties
> > > 
> > > ...and so on.
> > 
> > That would require to define all the options at compile time. Any option
> > name change or type or removal would break the API.
> 
> If we provide a #define for each common option, those could also change
> in between releases. If an option is renamed, we can change the #define,
> but for options removed, added, or the option type changed, the API would
> be broken with your suggested approach as well.
> 
> So no matter which of both approaches is implemented, the API can break
> between releases. The only way of preventing that in both cases is avoiding
> to merge JSC patches in stable release branches that include changes to the
> JSC options — and allowing changes in between major releases.

But in the case of not autogenerated code, we would only provide macros for a few common options, that are more unlikely to change. We can deal with changes in any case, we have experience with that when the DOM bindings were autogenerated, and that's the main reason why I want to avoid generated code here :-) I don't know how we could deal with range options using properties, unless we consider them a string of the form begin:end and parse it. With explicit API we could simply add get/set_range (options, begin, end);

> > > > /**
> > > >  * JSC_OPTION_USE_JIT:
> > > >  *
> > > >  * Allows the executable pages to be allocated for JIT and thunks if %TRUE.
> > > >  * Type: %G_TYPE_BOOLEAN
> > > >  * Default: %TRUE
> > > >  */
> > > > #define JSC_OPTION_USE_JIT "useJIT"
> > > > 
> > > > It would be something like that.
> > > 
> > > It looks to me that we could even generate the code of such JSCOptions
> > > class making use of the JSC_OPTIONS() macro to autogenerate the parts of
> > > the jsc_options_class_init() which install the properties, and have a
> > > helper function to convert “someOptionName” internal camel-cased option
> > > names to GObject style snake-case “some-option-name” strings. Note that
> > > JSC_OPTIONS() even includes descriptions for the options, so those could
> > > be used when instantiating the GParamSpecs for the properties and then
> > > the option descriptions will automatically get picked by gtk-doc.
> > > 
> > > I think that even if the generated JSCOptions class does not have the
> > > jsc_options_set_some_option() and jsc_options_get_some_option() methods,
> > > the GObject properties functions will work well:
> > > 
> > >   JSCOptions *options = jsc_options_get ();
> > >   g_object_set (options, "use-jit", FALSE, NULL);
> > 
> > Yes, without the public getter/setter, it might work.
> > 
> > > If additional type safety there is desired, one can use g_object_setv()
> > > and g_object_getv(), too.
> > > 
> > > Or is there any reason I am missing to not reuse the existing GObject
> > > properties machinery?
> > 
> > My initial idea was to use GObject properties indeed, similar to
> > WebKitSettings. API stability was my main concern.
> 
> As I outlined above, the approach you suggested has exactly the same
> potential API stability issues as using GObject properties.

Not exactly the same, an option rename wouldn't be a problem without auto-generated properties. And again, the amount of options with a name in the API would be low.

> Therefore
> I would go with the solution that feels more natural in a GLib/GObject
> API and use object properties.

I'm not sure an object with no public API but a getter for the global instance is "natural" :-) I know GObject properties are also public API, but still.

> > > Also: Maybe I would call this “JSCSettings”, to keep the name consist
> > > with “WebKitSettings”.
> > 
> > Also thought about it, but I'm not sure. JSC options are not like WebKit
> > settings, so we don't really need to be consistent. In the case of JSC,
> > options are normally set at the very beginning of the program execution and
> > never changed again.
> 
> FWIW, I have nothing against the “JSCOptions” name. If you think using it
> helps to make it clearer that they are intended to be set once at start
> (in contrast to a “FooSettings” name), then let's use it :-)

I'm not sure either, but I'm sure we don't need to be consistent with the web view settings.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180821/00b46917/attachment-0001.html>