[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