[PATCH] add documentation about backend naming for VMOD authors

[Geoff Simmons]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/02/2015 09:32 AM, Dridi Boukelmoune wrote:
> Sorry for the frenchism but it's turning into a "dialogue de sourd"
> :(

Dridi, mon ami, ce n`est pas grave. %^)

My impression is that we're all insistently agreeing with each other.

> In the "Writing a director" documentation I *recommend* directors 
> writers to back their director with a *VMOD object* because VMOD 
> object come with a *unique* vcl_name and don't outlive the VCL's 
> lifespan. It makes VMOD objects in my opinion the best facility to 
> write a director.

Certainly, that's a good solution -- as long as your use case allows
for it. You could even have an object generate multiple backends,
using the object's name for a "safe namespace", within which it
creates unique names (say by adding the ".%d" suffix).

And you've made it clear that you're fully aware that using objects is
not the only, necessary solution -- and even then, the VMOD has to go
through the motions of using the object's vcl_name for backend names.
However the VMOD goes about it, uniqueness of naming with all of the
consequences is something it has to take care of (or not, and take the
consequences).

Adding something to the Varnish/VRT interface to make it work right
will go a long way to making this painless.

D'accord?

(Sorry, slink is better at that than I am.)


Best,
Geoff
- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWNzt5AAoJEOUwvh9pJNURPF8QAIj8j5I82lrrlc6H3ipS9JF8
p+tbVP8xjV3NPT0P7UTADT/6+9j/tq/sG7x/oogn9qQKRW/nJHO77kyGb2Yl3XTm
smm5FvpxRb0PqIVOZz3RHUjKyTvMGji0k78pIay33SfyPwRW076T3QYzEWVluWfI
QZak19Pbmf73Sn+3N+Szr5itQYo2Mw1DeHynOv3MtKVqk/NWNEQRJapvcL5497n6
nZYd105MQd56b/xg+v5x4AUN1XBWAjpCl3OAefMKAgYrWMJ4ceobUqPtfy4yJsxO
6D8uH5Xg4Oth2UKdaTmidzWg47l2CCG/ErJmrHbYaX3k0IPavT5ifKUdRmV3i7ZI
GRmSJuJSbUhKP8IKg3j51Ut3B6Az+//uZXR/UhsuehFl06dfy/2ETDoofWUY6vZu
lF49vZ70dIa1iQ7h+WLUEGDfI6xCP1dlW8yQ2ptZSCZo2qN0CndufMZU9hhzYewP
+zPnQEoFDGx/Nlm/9LFnm/VV0EGtzv3ueGZV6c2UxiwfNZVPMvJw8DK1B75Rpk8O
bTOH8LFavmZU46BG53H2g2PDFYDp8dqsEAhZKf5lAKlhDpY0EmZFHq88RMUZ142F
eMWdTegAyKrWx9dz/tX7P4TE4kKw3juopSSeNwAUbLaFGjrkXh6OdPuUtTAfhd15
b6PGXhizhR7jJKrZkIQO
=prCa
-----END PGP SIGNATURE-----