<div dir="ltr"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">Em ter, 18 de out de 2016 às 15:07, Carlos Garcia Campos <<a href="mailto:cgarcia@igalia.com" class="gmail_msg" target="_blank">cgarcia@igalia.com</a>> escreveu:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El mar, 18-10-2016 a las 13:29 +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">
> > It doesn't need to be just a wrapper, because to wrap the JSC API<br class="gmail_msg">
> > you<br class="gmail_msg">
> > can just use the existing API. As I said, this depends on how we<br class="gmail_msg">
> > design<br class="gmail_msg">
> > the value object for example, if we use a different subtype for<br class="gmail_msg">
> > every<br class="gmail_msg">
> > value type, we definitely want to use GObjects. I really don't<br class="gmail_msg">
> > think<br class="gmail_msg">
> > there's that much overhead in using GObject, compared to boxed<br class="gmail_msg">
> > 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">
><br class="gmail_msg">
> Well... I don't really see a point on having subtypes for every kind<br class="gmail_msg">
> of value... maybe code maintainability, but I don't think this will<br class="gmail_msg">
> be hurt if we use only one type for values (yet). Feel free to<br class="gmail_msg">
> convince me though. And it's a good idea to make JSCValues initially<br class="gmail_msg">
> unowned.<br class="gmail_msg">
<br class="gmail_msg">
I'm afraid it works the other way around :-) you have to convince us<br class="gmail_msg">
that using boxed types is better, or prove that the GObject overhead is<br class="gmail_msg">
so high that it's worth not using them. We could implement the desired<br class="gmail_msg">
features for a boxed type (ref counting, floating refs, weak refs,<br class="gmail_msg">
etc.) but we would be reinventing GObject in the end. Note that we can<br class="gmail_msg">
have a single JSCValue for everything but still make it a GObject<br class="gmail_msg">
instead of a boxed type. </blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> Yes. It really wasn't clear... When I wrote that paragraph, I was already agreeing with JSCValues being GObjects. I was just not finding a good reason for subtypes :P GObjects are really needed, mainly because of the possibility of making them initially unowned and also because of memory management.</div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > hace a<br class="gmail_msg">
> > rule that it needs to be approved by two reviewers, so maybe you<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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">
><br class="gmail_msg">
> So, considering your previous comments, we can do something like this<br class="gmail_msg">
> for a start:<br class="gmail_msg">
><br class="gmail_msg">
> Objects:<br class="gmail_msg">
> o JSCContext<br class="gmail_msg">
> o JSCValue<br class="gmail_msg">
> o JSCObject<br class="gmail_msg">
> * JSCError (JSCArray, JSCDate and other stuff should come here too)<br class="gmail_msg">
<br class="gmail_msg">
Why is Object special? So, we use a single JSValue for everything<br class="gmail_msg">
except Object? I think we should be consistent here. I know that's what<br class="gmail_msg">
the C API does, but this is what I meant when I said that our API<br class="gmail_msg">
doesn't necessarily need match the C API 1 to 1.<br class="gmail_msg">
<br class="gmail_msg">
And then JSCError is also a JSCObject? why is this a different object<br class="gmail_msg">
too? I think it should be named JSCException, btw.<br class="gmail_msg">
<br class="gmail_msg">
> Methods:<br class="gmail_msg">
> JSCContext* jsc_context_new();<br class="gmail_msg">
> JSCObject* jsc_context_get_global_object(JSCContext*);<br class="gmail_msg">
<br class="gmail_msg">
If we add convenient methods to JSCContext to deal with the global<br class="gmail_msg">
object we can leave this for now. For example, the Objc API allows to<br class="gmail_msg">
do something like this:<br class="gmail_msg">
<br class="gmail_msg">
context["foo"] = @"bar";<br class="gmail_msg">
<br class="gmail_msg">
This means, create a string value with "bar" contents and set it to the<br class="gmail_msg">
global object of context as property "foo". And the same to get a<br class="gmail_msg">
value;<br class="gmail_msg">
<br class="gmail_msg">
JSValue *foo = context["foo"];<br class="gmail_msg">
<br class="gmail_msg">
This is super convenient, we can't do the same in C, but we can still<br class="gmail_msg">
add convenient methods to do that, for example:<br class="gmail_msg">
<br class="gmail_msg">
jsc_context_set_object (context, "foo", jsc_value_new_string ("bar"));<br class="gmail_msg">
JSCValue *foo = jsc_context_get_object (context, "foo");<br class="gmail_msg">
<br class="gmail_msg">
Note that we can pass the returned value of jsc_value_new_string (or<br class="gmail_msg">
jsc_string_new if we use subtypes) if we make them initially unowned<br class="gmail_msg">
and the context consumes the floating reference.<br class="gmail_msg">
<br class="gmail_msg"></blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Now I got your point! I was thinking only in making the API more GObject-like but your proposal is much better. We can have only JSCContext and JSCValue with subtypes and do everything we need with them! :] I was complaining about subtypes thinking that they would be JSCValueString (or JSCStringValue) and only add more typing without need, but the way you're thinking is completely worth it!</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">We can have:</div><div class="gmail_msg">o JSCContext</div><div class="gmail_msg">o JSCValue</div><div class="gmail_msg"> * JSCString</div><div class="gmail_msg"> * JSCBoolean</div><div class="gmail_msg"> * JSCCallback</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">and so on and only use the context to set and get those values. It's indeed a very good abstraction! :]</div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> JSCValue* jsc_context_evaluate_script(JSCContext *, gchar* script,<br class="gmail_msg">
> JSCError* err);<br class="gmail_msg">
<br class="gmail_msg">
Note that evalueScript is not the only function that can raise js<br class="gmail_msg">
exceptions, other methods like jsc_value_ge_string() for example, can<br class="gmail_msg">
also raise a exception. Adding a GError like parameter to all our API<br class="gmail_msg">
methods wouldn't be very convenient, and if a function changes from not<br class="gmail_msg">
raising exception to raise exceptions, we would need to change the API<br class="gmail_msg">
to add the error parameter. Again, following what Objc API does, we<br class="gmail_msg">
could add a exception handler to the JSContext that receives the<br class="gmail_msg">
JSCException object, and assume that any API method can raise a<br class="gmail_msg">
exception in the context.<br class="gmail_msg"></blockquote><div>Yes. We can have the JSCException subtype and implement a default exception handler in JSCContext. The user will be able to change the default exception handler via jsc_context_set_default_exception_handler and inside every API call, if any function throws an exception, we call the default exception handler and return. Just thinking: maybe we can have a "exception" signal in which the user only connects his exception handler, this way we can have the default exception handler and also the user's running. In both ways we don't need to add the exception object as a parameter and don't have problems with possible API changes.</div><div> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> JSCValue* jsc_value_new_string(JSCContext*, gchar *value);<br class="gmail_msg">
> JSCValue* jsc_value_new_boolean(JSCContext*, gboolean value);<br class="gmail_msg">
> JSCValue* jsc_value_new_number(JSCContext*, double value);<br class="gmail_msg">
<br class="gmail_msg">
I think we should have different methods for number new_int32,<br class="gmail_msg">
new_uint32, new_double<br class="gmail_msg">
<br class="gmail_msg"></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> gboolean jsc_value_is_string(JSCValue*);<br class="gmail_msg">
> gboolean jsc_value_is_boolean(JSCValue*);<br class="gmail_msg">
> gboolean jsc_value_is_number(JSCValue*);<br class="gmail_msg">
<br class="gmail_msg">
All is methods are not needed if we use subtypes, we would have<br class="gmail_msg">
JSC_IS_STRING, JSC_IS_BOOLEAN, etc.<br class="gmail_msg"></blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">+1 for subtypes :] </div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> gboolean jsc_value_is_object(JSCValue*); //or maybe<br class="gmail_msg">
> jsc_object_new_from_value<br class="gmail_msg">
> gchar* jsc_value_get_string(JSCValue*);<br class="gmail_msg">
<br class="gmail_msg">
In this case, the getters are not returning an internal value stored,<br class="gmail_msg">
that's why you return gchar* and not const gchar* I guess. If we use a<br class="gmail_msg">
single JSCValue type, I would call the methods to instead of get, in<br class="gmail_msg">
this case folloiwing the C API:<br class="gmail_msg">
<br class="gmail_msg">
JSValueToStringCopy() -> jsc_value_to_string()<br class="gmail_msg">
<br class="gmail_msg">
if we use subtypes, then get would make more sense probably<br class="gmail_msg">
<br class="gmail_msg"></blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br></div><div class="gmail_msg">Wouldn't we have subtype functions to retrieve the values? This way we could add specific conversions if needed... Like jsc_date_to_string and jsc_date_to_gdate for instance... Just thinking... :P Keeping just jsc_value_get_date is also cool for me though.</div><div class="gmail_msg"><br></div></div></div></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> gboolean jsc_value_get_boolean(JSCValue*);<br class="gmail_msg">
> gdouble jsc_value_get_number(JSCValue*);<br class="gmail_msg">
> JSCObject* jsc_value_get_object(JSCValue*); //or maybe<br class="gmail_msg">
> jsc_object_new_from_value<br class="gmail_msg">
> JSCObject* jsc_object_new(JSContext*);<br class="gmail_msg">
> gboolean jsc_object_has_property(JSCObject*, gchar* property_name);<br class="gmail_msg">
> JSCValue* jsc_object_get_property(JSCObject*, gchar* property_name);<br class="gmail_msg">
> void jsc_object_set_property(JSCObject*, gchar *property_name,<br class="gmail_msg">
> JSCValue* property_value);<br class="gmail_msg">
> gboolean jsc_object_delete_property(JSCObject*, gchar*<br class="gmail_msg">
> property_name);<br class="gmail_msg">
<br class="gmail_msg">
I would leave the JSCObject for now. A first patch could just add and<br class="gmail_msg">
retrieve simple values to the context.<br class="gmail_msg">
<br class="gmail_msg"></blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Agreed! </div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I still miss the details about the memory management. Does an object<br class="gmail_msg">
created with jsc_value_new protect the value from being garbage<br class="gmail_msg">
collected? how do you plan to handle that?<br class="gmail_msg">
<br class="gmail_msg"></blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">When I proposed boxed types, I was thinking that they would reduce the complexity, but instead, they add some complexity because of the memory management model used by them... with GObjects we can make JSCValue extend GInitiallyUnowned and in the jsc_context_set_object_property we ref_sink them. I think that we can protect all JSValuesRef inside JSCValue and release them in dispose (also setting the JSValueRef to NULL to avoid duplicate releases).</div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Implementing this API will let the client execute javascript,<br class="gmail_msg">
> retrieve values returned from it, create new values and inject them<br class="gmail_msg">
> as global object (window) properties. Is this enough for a start?<br class="gmail_msg">
> Gratton and others, which kind of stuff do you need to do with JSC?<br class="gmail_msg">
><br class="gmail_msg">
> One think is a little fuzzy for me. It's <br class="gmail_msg">
> > > > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > 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.<br class="gmail_msg">
> > 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<br class="gmail_msg">
> > one.<br class="gmail_msg">
> ><br class="gmail_msg">
><br class="gmail_msg">
> Thanks for this info. I'll check them all :]<br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> webkit-gtk mailing list<br class="gmail_msg">
> <a href="mailto:webkit-gtk@lists.webkit.org" class="gmail_msg" target="_blank">webkit-gtk@lists.webkit.org</a><br class="gmail_msg">
> <a href="https://lists.webkit.org/mailman/listinfo/webkit-gtk" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-gtk</a><br class="gmail_msg">
--<br class="gmail_msg">
Carlos Garcia Campos<br class="gmail_msg">
<a href="http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3" rel="noreferrer" class="gmail_msg" target="_blank">http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3</a></blockquote></div></div></div></div>