GNOME Bugzilla – Bug 694115
Folks unusable from JavaScript
Last modified: 2018-09-21 16:01:00 UTC
I tried writing some example JS code using Folks and hit an immediate road block: Gee structures' elements are inaccessible from JS. If you iterate over them, their elements just show up as "undefined" (effectively the same as "null"). This seems to be primarily due to bug 639908, but I'm opening this bug in case we find any other blockers along the way (and to make it more searchable).
I wonder whether it would be worthwhile to add a parallel version of the problematic APIs solely for bindings, that returns a well-understood data type like GList?
(In reply to comment #1) > I wonder whether it would be worthwhile to add a parallel version of the > problematic APIs solely for bindings, that returns a well-understood data type > like GList? I would be strongly against doubling the number of API entry points in folks and the large maintenance burden that would impose. Add to that the fact that GList is easy to misuse in Vala (creating leaks or use-after-frees), which is why we went with libgee in the first place.
The core problem (bug #639908) still exists, but we've fixed some issues in the meantime: bug #702490, bug #703402. With these in place (the latter pending review), Folks is usable enough from JS to read Individual/Persona details* and even use Tpf.Personas to initiate Telepathy chats, calls, etc. * There is the major caveat that reading most Individual/Persona fields requires a shim Vala or C library to de(marshall) values stored in the many Gee structures we use (due to bug #639908). JS can get the pointer to, eg, persona.im_addresses, but that must be passed along to a shim library to pull out the details required by the JS code and return it in a format that JS can use (eg, a GArray of strings which will be automatically converted to a string array for use in JS).
Does this require any more work on the folks side (assuming we don’t go with the suggestion from comment #1), or are we just waiting for a GIR miracle (bug #639908)?
(In reply to comment #3) > reading most Individual/Persona fields > requires a shim Vala or C library to de(marshall) values stored in the many Gee > structures we use Isn't that just my suggestion from Comment #1, but copied into each g-i project that consumes Folks data? I'm not sure I see the advantage, tbh.
(In reply to comment #5) > Isn't that just my suggestion from Comment #1, but copied into each g-i project > that consumes Folks data? I'm not sure I see the advantage, tbh. Sort of, except the g-i projects would only shim the APIs they actually use, which I suspect might be a lot less than what folks provides.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/54.