Hello!
On Fri, Jun 6, 2014 at 1:15 PM, Aapo Talvensaari wrote:
> So would it be okay to advice users of my lua-resty-session module to do
> this:
>
> local session = ngx.ctx.session = ngx.ctx.session or require
> "resty.session".start()
>
This line is a bit too long and rather confusing :)
> What I mean is that:
>
> 1. I need to load module require "resty.session"
> 2. Start session only once, and if user tries to start it many times in user
> lua scripts or modules, always return the same Lua table that is bound to
> current request (on single request I need to keep exactly one single
> session, that is not require "resty.session" but require
> "resty.session".start().
>
Personally I'd just let the user do the old school way. Too much magic
may defeat clever user's optimization efforts ;) For example, fetching
ngx.ctx from scratch is also expensive (even more expensive than
fetching a Lua global).
> Or should my module automatically reqister ngx.ctx.session variable?
It is generally not a good idea to pollute the key space of ngx.ctx
with your libraries' private data :) There is a risk of collisions
with other things. But you could do that if you explicitly state the
key you'd insert in the protocol (i.e., in docs).
As I've said, fetching ngx.ctx from scratch is expensive (the
metamethod call involved in ngx["ctx"] is expensive). The user may
choose to pass the resulting ctx table around by explicit function
arguments around her own Lua code base. So better leave the choice to
your user :)
> Or
> should I just advice users that if require "resty.session".start() is called
> many times, each call will overwrite the previous session, so that the user
> should himself/herself manage the session variable himself.
Yes, this is the recommended approach. Be simple and be explicit :)
> The thing here
> is that sessions are so in the core of web programming (ie. in php you just
> call session_start (or in case of autostarted sessions you don't need even
> that) and then use global request bound $_SESSION, and that's it). You don't
> need even call session:save as PHP will automatically call session saving
> functionn.
I know. But IMHO usually there are more per-request data in addition
to the session token itself. Better give the user the freedom to
manage per-request data in her own favorite way :)
>
> Of course, the PHP's way is not the only or even best way to archieve this.
> I'm just looking a way that would be most natural in OpenResty. The current
> API of my lua-resty-session doesn't look too bad in that regard, but it has
> these tiny problems. Say that user has Lua module A and B and both are
> utilized in every request. It would be nice just to say local session =
> require "resty.session" in each of these modules. But as you can see, this
> just returns the same table always and that cannot be used as each request
> need dynamically generated session everytime.
Try always passing the per-request data (including sessions)
explicitly via these Lua modules' method arguments or constructor
arguments. This is the recommended paradigm. The data scoping issue
can be really annoying and we'd better be more explicit here. Plus,
this also helps performance a lot :) For example, I recently avoided
the scattered ngx.ctx calls across our Lua CDN code base by passing
the resulting ngx.ctx table around explicitly by function call
arguments, which gives almost 15% overall speedup in my local
benchmark.
Magic always comes at a price and I've been regretting adding too much
magic to existing ngx_lua's Lua API, which makes future optimizations
and tuning harder than desired. I'll try to address these by adding
new better alternatives and deprecating existing bad ones :) And yeah,
I'll try hard not to break backward compatibility :)
Again, there are just my personal opinions :)
Best regards,
-agentzh
