On Thu, 20 Jul 2017 15:26:52 +0200 Adis Nezirovic <[email protected]> wrote:
> On 07/20/2017 02:55 PM, Willy Tarreau wrote: > > So you can have : > > 0 or 1 "listen" > > 0 or 1 "frontend" + 0 or 1 "backend" > > > > Just a few ideas come to my mind : > > - is it possible to store arrays into arrays ? I mean, could we have > > for example core.proxies["foo"].side[FRONT|BACK] where each side is > > set only when the two differ ? > > > > - or is it to return a list (1 or 2 elements) ? That would be even more > > convenient to use. If you have "p = core.proxies[foo]" and can use p > > then next(p), you're sure to always scan everything. > > > > - otherwise I like the principle of being able to force the type using > > a prefix "@f:" or "@b:" in front of the name. But we must be careful > > not to insert duplicates. So probably by default only "listen" instances > > would be created without the "@" prefix. My initial idea was to be able > > to always return the plain form and point to whichever exists, but for > > enumeration it would require to keep only the "@" form, which might be > > more complicated. > > We currently use a variant of second proposal, when working internally > with backend/frontends with same name, type/side should still be > indicated. Simple list/array might be easiest thing to implement. Ok. After brainstorm, I think that the it will be netter to keep the current behaviour to avoid breaking existing Lua implementations. Adding other entries with prefix "@f:" and "@b:" in the same list that the existing will disturb existing Lua which browse the lists. Returning a list (point 1 & 2) also break it. I think that the most reliable way is adding anoter tree. We keep the "proxies" tree base with existing, and we add two trees "frontends" and "backends" which contains respecticely the list of frontends and backends. Or another tree called "all_proxies" which contains names and a list of frontend/backend with the same name. > >> Also, apply the same logic to the 'Listener' and 'Server' classes. > > > > These ones do not support duplicate names so we should not need to impact > > them. > > This is just for convenience and uniformity, Proxy.servers/listeners > returns a table/hash of objects with names as keys, but for example when > I want to pass such object to some other Lua function I have to manually > copy the name (or wrap the object), since the object itself doesn't > expose name info. You're right, it will be better adding the name in the object. I will do this. Thierry
