suggestion about expansibility of the data

[Chieu]

the way of the module context can meet many requitments. But some others
can't be implemented by the module way.
for example,
In the struct"ngx_http_upstream_rr_peer_t", I want add a variable to count
how many times I haved request this upstream.
If there is a reserved pointer, I can use it point a struct I have defined
in my module. But now,I must modify the source code and when I want to
replace with a new version nginx, I have to re-modifiy the code.

ngx_http_request_t can expand datas with the module context, but other data
struct can't use module conext?

thank you

2009/6/23 Maxim Dounin <mdounin at mdounin.ru>

> Hello!
>
> On Tue, Jun 23, 2009 at 06:05:19PM +0800, Chieu wrote:
>
> > hi, developers
> > Because of the modularity of nginx, I can extend the new function easily.
> > But there are some requirements which need to modify the original source
> > code.
> > For example:
> > I want to add a variable which records the count of requests sent to each
> > upstream. And I must add a variable into the struct
> > "ngx_http_upstream_rr_peer_t", when round robin get the upstream ,the
> > variable++ . This way, I shoud modify the source code of the upstream
> > module.
>
> You may easily write transparent upstream balancer module that
> does this (just counts and passes everything to the real
> balancer).  Without nginx code modifications.  It's not really
> efficient due to extra function calls, but it will work.
>
> > I think if the struct "ngx_http_upstream_rr_peer_t" have a reserved
> > pointer(void *), which reserved for others developing new modules.
> > Totally, I think the modularity of nginx just resolved the expansibility
> of
> > function. But if the I want to expand some import data like the struct
> > "ngx_http_request_t", I must modify the original source code. And if
>  some
> > important struct adds a reserved pointer, I think the data of nginx will
> be
> > easily be extend.
>
> I don't really understand the question, but for any data you may
> use either your module context (every module has pointer to it's
> context stored in ngx_http_request_t) or variables (if you need
> something that survives internal redirects).
>
> Maxim Dounin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090623/825b7783/attachment.html>