Well-known Attributes

[eguzki]

Overall, looking super good.

Kuadrant's well known attributes are another value added by Kuadrant to be leveraged by users.

[alexsnaps]

some small comments:

We should follow up to ensure the sections marked as These attributes need confirmation if they are all actually available to be requested by the Wasm-shim. are confirmed.

Just to make it clear to all, these aren't spec'ed anywhere afaik, so that every other host might have a different set of those available...

[maleck13]

The wasm ones? Should we consider removing those or not adding the to the public facing docs? @guicassolato what if the public facing docs communicated only things like the request , auth and rate limit attributes?

[alexsnaps]

Some notes here from me, feel free to ignore for now, but I think we'll have to account for these:

• Currently the Rust SDK makes no difference between the property being null or actually being "not found". This might be an issue for us if we want to support multiple hosts....
• A property's value are just pub type Bytes = Vec<u8>... if there is, amongst different hosts, different types to be returned for a given property, how would we deal with these? Minor issue, if it ever happens even, but raises another question...
• Currently, Envoy's RL protocol "only" lets us pass String pairs thru the descriptors. Further more, Rust only allows valid UTF-8 strings... So we'd probably need to "stringify" the different types... Integers can be integer literals in Limitador's expression language. Timestamps could "simply" be ISO 8601 formatted strings. Which leaves us with more complex data structures... Depending on what we'd want to support as operators and whether these need to be evaluated in Limitador, we'll have to either support literals for at least Arrays and Maps, but we'd be left with Metadata & Node (that's if I don't miss anything)... Again, if these are to be evaluated in Limitador and NOT with the wasm-shim.
• Finally, I'm unsure what someone would use the wasm.* attributes for? If there is no actual use for them today, should we just avoid adding them now?

[maleck13]

@alexsnaps I am a fan on not making those wasm ones available. Or at least not documenting publicly for now. I can imagine you can get a long way with more complex use cases with the request , auth and rl properties @guicassolato WDYT

[guicassolato]

Should we consider removing those or not adding the to the public facing docs?

I'm okay with omitting the Wasm attributes. What about the Proxy configuration ones? Do we need them?

[alexsnaps]

What about the Proxy configuration ones? Do we need them?

I see you applied the same logic there, right? i.e. remove them until we actually have a use case that requires them?