On Wed, Feb 17, 2010 at 7:07 PM, Valery Kholodkov
<valery+nginxen@grid.net.ru> wrote:
>
> In particular I don't like the presence of "eval_subrequest_in_memory" directive at all, because it specifies which way of internal communication the module needs to use, which doesn't make any sense for end user.
>

Thanks for replying to my pull request (although indirectly). Yeah, I
don't like the name of that directive as well. I chose that just
because I can't find a better name at that moment :P

> Second, the contributed code allocates a buffer and uses it in order to assemble the output of subrequest in it. This allocation can be totally avoided, if an appropriate state machine is implemented.
>

I just copied (almost) the way that ngx_http_upstream does buffered
outputing ;) To be honest, I didn't and don't see how that allocation
can be totally avoided for general use cases. Silly me! :P

> As soon as these issues are resolved, I'll accept this code.
>

It'll be great if you provide some more elaborate suggestions or even
patches to my patches if you do have the tuits :)

Just as Piotr mentioned ealier, the initial motivation for my ngx_eval
branch is to provide support for ngx_drizzle + ngx_rds_json. Adding
subrequest-in-memory support to every content handler/upstream handler
*with* output filter support is boring and no fun. So I chose to fix
ngx_eval rather than my content handler/upstream modules ;)

Thanks!
-agentzh

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx