Closed thibaultcha closed 11 months ago
Merging #449 (9c661a8) into main (db88b15) will increase coverage by
0.02525%
. Report is 1 commits behind head on main. The diff coverage is93.38843%
.
In fact speaking about this API, I would even be in favor of merging the setter/getter functions into a single FFI call: set_host_properties_handlers, as I do not see the benefit of splitting the operation in two different calls, it feels unnecessarily bloated or "copy-pasted" for easy-mirroring.
@hishamhm I think I am going to make this change too; it would avoid an additional Lua/C round-trip on a hot code path, avoid duplicating error handling from the caller, and provide a smaller surface API which imho is always good, easier to document and grasp, etc (avoids the proliferation of functions exposed to the user). If the caller wishes to only set the setter or getter, they can call proxy_wasm.set_host_properties_handlers(getter, nil)
. Sounds good?
If the caller wishes to only set the setter or getter, they can call
proxy_wasm.set_host_properties_handlers(getter, nil)
. Sounds good?
Sounds great!
Guard feature to OpenResty builds.
This is the only change I would argue against: the original design of host-defined properties kept the Lua and non-Lua sides well separated, and this was proven when I made three different implementations of the Lua side (FFI, Lua/C, Lua bridge APIs) and ngx_proxy_wasm_properties.c remained unchanged -- there was nothing FFI-specific (or even Lua-specific) about the additions there. My reasoning was that, as an Nginx module that can used with and without OpenResty, it is reasonable to think that a different non-Lua-driven Nginx application could still want to register a C function callback as a driver for dynamic host-defined properties.
I don't feel strongly about this, but I just wanted to point out the rationale of the design (otherwise the work of ngx_proxy_wasm_properties_set_ffi_getter
/setter
could simply be done directly in ngx_wasm_lua_ffi.c
?) and the use-case.
If that is ever a use-case the guards can be changed/removed and the struct members renamed (I doubt it ever will of course). In the meantime, the guards help the reader better mapping what parts of properties.c
have to do with what other parts of the codebase, and what can be eliminated (from the mind) when working on vanilla Nginx builds - it's mostly reader-centric (maintainer-centric). properties.c
isn't that easy to follow because it itself represents multiple concepts (Nginx-mapped variables, custom but hard-coded C handlers variables, and now custom FFI handlers variables, but only for "host properties", a getter and a setter symmetry for all properties, plus an rbtree to store them, etc...), so being able to eliminate parts of it for specific work is helpful imho.
Changes atop #431:
_handler_pt
,host_props
) and "host properties getter/setter" from within the FFI. Since the feature can only be used through the FFI, proxy_wasm_properties know it as "FFI host props getter/setter".crc32
for rbtree hashes like all other rbtrees in the codebase (and movehash_str
to HTTP-only builds).dd
, comments, assertions for readers).proxy_wasm.set_property_(s|g)etter()
toproxy_wasm.set_host_properties_(s|g)etter()
-> less confusing sinceset_property_getter
feels like setting a single property getter handler (and doesn't mention "host properties), while all other parts of the code refer to host properties in plural form. It's "host properties" or "host_props" for code abbreviations. In fact speaking about this API, I would even be in favor of merging the setter/getter functions into a single FFI call:set_host_properties_handlers
, as I do not see the benefit of splitting the operation in two different calls, it feels unnecessarily bloated or "copy-pasted" for easy-mirroring.~ Merged intoset_host_properties_handlers
.int
).store_c_value
withoutretrieve
in setter (for the reader).set_r
patch from Hisham).proxy_wasm.get/set_property()
err return value, this error has no stacktrace hence contains some format with the property key.--- grep_error_log
.Overall, the changes make the feature increase project coverage instead of decreasing it.
Plus an additional fix in dynamic builds:
Without this fix, the wasm_filter_module handlers execute before
body_filter_by_lua
, which isn't the desired behavior (i.e. same as static builds). This patch fixes FFI getter/setterbody_filter_by_lua
sanity tests, which were caught thanks to proper use of--- grep_error_log
.