> 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. _______________________________________________ grilo-list mailing list grilo-list@gnome.org https://mail.gnome.org/mailman/listinfo/grilo-list
