Re: lua-factory: the analysis of the changes proposed in #753141

[George Sedov <radist morse gmail com>]

> All in all, I agree with you. It is over-complicated but I don't see
> how
> it could break with several operations from grilo (like, several
> async
> search/browse) as each OperationSpec stays in _G related to its
> operation-id. If you *can* break it easily, tell me how or even
> better,
> create a test under lua-factory [1] and attach to the BZ :-)
>
> [1] https://git.gnome.org/browse/grilo-plugins/tree/tests/lua-factory

Each operation spec stays with its own operation-id as a key, yes, but
ALSO one is stored as "current" as you can see in
grl_lua_library_set_current_operation(). Here's the piece of code
responsible for it:

1686  lua_getglobal (L, LUA_ENV_TABLE);
1687  lua_pushstring (L, GRILO_LUA_OPERATION_INDEX);
1688  lua_pushlightuserdata (L, os);
1689  lua_settable (L, -3);

You can see that GRILO_LUA_OPERATION_INDEX is quite global.

As for the test, it's not that easy. We are talking race conditions
here, so an automated test would be a challenge. And a pointless one at
that, since you agree that moving away from global table is ultimately
a good idea anyways :)

> So, this changes a lot. What I like least is that you are splitting
> functions provided by grl-lua-library. I do like grl as a library -
> globally accessible.

> aside of `callback` which is the only one I think it makes sense to
> keep as an argument here.

Why is callback so different from options in your opinion? They are
both context-dependent in the very same way. They both do not make any
sense outside of their respective scopes for which they were created.
And they both do not belong to the globally accessible library, IMO.