After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763089 - Declare API required by source
Declare API required by source
Status: RESOLVED OBSOLETE
Product: grilo
Classification: Other
Component: lua
git master
Other Linux
: Normal normal
: ---
Assigned To: grilo-maint
grilo-maint
Depends on:
Blocks:
 
 
Reported: 2016-03-04 11:14 UTC by Juan A. Suarez Romero
Modified: 2018-09-24 09:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
lua-factory: declare api required by source (10.47 KB, patch)
2016-03-15 23:28 UTC, Victor Toso
needs-work Details | Review

Description Juan A. Suarez Romero 2016-03-04 11:14:36 UTC
Thinking on future changes inside the Lua API we expose to sources, we don't have a way to know if a source was written for a specific API or another.

It would be useful if sources declares someway the API they rely, so if we change it in Lua we can find out if the source is still compatible with the new changes (and thus we can use it) or if it is incompatible, and then better not load it.


A possible way could be tagging API with a version number X.Y. When adding we change the API so it is still compatible with previous one, we can tag it as "X.(Y+1)". And if we break it,use "(X+1).0".

On the other side, Lua sources would use "api=X.Y" to say it can use apis tagged as X.Y, X.(Y+1), X.(Y+2), and so on.
Comment 1 Juan A. Suarez Romero 2016-03-14 08:22:37 UTC
(In reply to Juan A. Suarez Romero from comment #0)
> On the other side, Lua sources would use "api=X.Y" to say it can use apis
> tagged as X.Y, X.(Y+1), X.(Y+2), and so on.


I'll put an example. Let's say my Lua API is 4.2.

Now I introduce a new function in the API. As I'm breaking nothing, the new API version will be 4.3.

This means that any source tagged as 4.0, 4.1, 4.2 or 4.3 will be compatible, and thus loaded by Grilo.
Comment 2 Victor Toso 2016-03-14 09:39:06 UTC
(In reply to Juan A. Suarez Romero from comment #1)
> (In reply to Juan A. Suarez Romero from comment #0)
> > On the other side, Lua sources would use "api=X.Y" to say it can use apis
> > tagged as X.Y, X.(Y+1), X.(Y+2), and so on.
> 
> 
> I'll put an example. Let's say my Lua API is 4.2.
> 
> Now I introduce a new function in the API. As I'm breaking nothing, the new
> API version will be 4.3.
> 
> This means that any source tagged as 4.0, 4.1, 4.2 or 4.3 will be
> compatible, and thus loaded by Grilo.

But if the source needs the new function from 4.3 it should not be loaded.
Yeah, I think it is a good approach!
Comment 3 Juan A. Suarez Romero 2016-03-14 17:01:57 UTC
(In reply to Victor Toso from comment #2)
> But if the source needs the new function from 4.3 it should not be loaded.
> Yeah, I think it is a good approach!

Right. In order to use the new function, the source should declare it requires API 4.3.

The API requirement would be mandatory and explicit.
Comment 4 Victor Toso 2016-03-15 23:28:23 UTC
Created attachment 324065 [details] [review]
lua-factory: declare api required by source

Staring from version 1.0 (major.minor) we can check if lua-factory is
newer enough for given lua source.
Comment 5 Bastien Nocera 2016-03-17 14:59:23 UTC
Review of attachment 324065 [details] [review]:

Looks fine otherwise.

::: src/lua-factory/grl-lua-factory.c
@@ +1319,3 @@
+
+  if (api_version == NULL) {
+    GRL_WARNING ("api_version not defined, unable to load lua-source %s (%s)",

Why a warning? Isn't a debug enough?

In fact, I would still try to load the source (in which case you could print a warning), and warn later on error.

This would also allow the source changes to be done separately.

@@ +1327,3 @@
+  if (strv == NULL || strv[0] == NULL || strv[1] == NULL) {
+    GRL_WARNING ("api_version not well defined. current version is %s",
+                 LUA_API_VERSION_STR);

printing the read version is probably more interesting than the current version.
Comment 6 GNOME Infrastructure Team 2018-09-24 09:42:11 UTC
-- 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/grilo/issues/83.