Hi Thierry,

On Mon, Jul 24, 2017 at 01:30:23PM +0200, Thierry FOURNIER wrote:
> 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.

Initially I wasn't much fond of this one but after some thinking I
convinced myself that it's probably the best solution. In fact you
never need to dereference a proxy by its name, unless :
  - you know its type (eg: for use_backend or to list servers)
  - you want to reference its table, which is already forbidden in
    duplicate names.

So in the end, being able to spot a proxy by its type+name, or being
able to lookup its name regardless of the type in case of a table seems
the best solution.  Hence frontends+backends+proxies.

> Or another tree called "all_proxies" which contains names and a list of
> frontend/backend with the same name.

It would add more confusion.

> > >> 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.
 
Thanks,
Willy

Reply via email to