The idea to have more than the #static vairables is good. But as hfs (and templates!) should be usable in different scenarios, i will try to show some possible shortcomings with ip OR user bound variables.
1. if your users are behind the same ip (college, company, university..) you have tu use $var-user ,as #var-ip would be the same for all users of this group.
2. If you make users login to get access with public names like guest,demo etc. , you should use #var-ip.
If i have understand what the goal of this new types of variables is, then i come to the conclusion that perhaps we could go a little further: instead of user OR ip depending variable, create a session-variable.
I know, there are no real sessions with hfs - but there is a workaround to create session-ids!
The idea how is the following:
1. we need that the program allows to define 2 things:
a) type of session id: none, user, ip or cookie
b) only if cookie defined: cookiename (default: hfs) + cookiemask (default: sid=)
the following steps are only needed if session-id type is cookie when %newsid% is set.
2. we need in the template a static variable #sid or %sid% , with an initial value.
3. hfs checks with every request the presence of the cookie-value. If there is no cookie that contains the sid, it sets %newsid% true and increments %sid%.
4. templates that use connection-dependent variables, update the cookie.
If a templater thinks using cookies is no good idea because some users fear that the cookies bite, they simply have not to use session- or connection depending vars, or define them as none,ip or user.
Also, for mars's initial proposal , as for what i propose to unify and make more universal the use of the new static vars, there will be the need for something more: some garbage collection, perhaps to do in events every xx hours/days, depending of your load on hfs.
This could be done in the following way for example: set with every request a #%sid%lastaccess=%now% (or use a table with addtable) and add %sid% to a #sidlist if it is not in it.
Then in events, in a for-loop check for every element the sid's lastaccess when the last access ocurred. When more than x time has passed, remove the sid form he lastaccess list or table and from #sidlist and invoka a {.clearsid|sid.} macro to free up the space.
This garbage collection shurely could be done in an easier way - this is no elaborated how to - but is not to forget if we don't want hfs to hang if we make no shutdown for days or weeks, as the amount of required storage space may grow heavy in some cases.
Poll