[vlc-devel] [PATCH] lua/http: load renderer discovery from xml/json page

Pierre Ynard linkfanel at yahoo.fr
Thu Aug 27 05:16:50 CEST 2020

> I find this harder to reason with since the 'rd' initialization is
> done somewhere else. It also adds another global variable which I'd
> rather avoid. I'm also unsure to understand what you mean by "and
> avoids crashing if the function is not defined.", how can the function
> be undefined?

What I meant is that hypothetically, if some caller loads and uses the
httprequests.lua module, without also loading custom.lua or something
else that defines get_renderer_discovery as a callable function, then
the code in httprequests.lua will crash upon get_renderer_discovery()
because of trying to call nil as a function. If instead httprequests.lua
just checks a variable, then missing setup simply means failed check and
unavailable feature - no crash.

Apart from the current code or this patch, there are still other
approaches, such as injecting the rd service object as an explicit
argument taken by get_renderers() (makes sense) and processcommands() (a
bit more awkward), instead of relying on global variables; it should be
noted here that httprequests.lua already relies on the global variable
mechanism for request parameters, passed to it through the global _GET
table set up by http.lua.

Yet another approach would be just not to put this stateful RD stuff
into httprequests.lua at all. get_renderers() is trivial, and the
main reason for processcommands() is grouping commands together. But
the whole httprequests.lua module doesn't really provide much code
factorization between different callers; the reason it was introduced
was to factorize code between just two versions, an XML one and a JSON,
of request handlers. If you take VLM handlers (again, not necessarily
the best reference), none of it was put into httprequests.lua.

Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

More information about the vlc-devel mailing list