global variables

[rejetto]

till now, scripting variables have always been bound to the browser connection.
such values were held while the connection was alive, only.

when you needed to keep a value in a global way, you had to save to files.
from next build i'm introducing global variables.

just an example:
by using this script event

Code: [Select]

[request]
{.set append|#x|%url%
.}
you will get a list of all requests that have been done to your HFS, over time.
all inside variable #x

then you may way to read this list, and may create a template section like

Code: [Select]

[read_list]
{.^#x.}
and by going to http://localhost/~read_list you would get the list.

i hope this example is quite clear.

this opens many possibilities that were not possible before.

at a syntax level, the basic idea is that global variables are used exactly like other variables, but have a symbol in front of the name.
at the moment i opted for #, as you can see in the example, but maybe you may have a better idea. i will consider suggestions.

[Foggy]

The only thought I have is how can you free the memory used by a global variable if it isn't cleared after the connection. This could potentially use up a fair amount of memory if they are not cleared when they are no longer needed.

[Mars]

The only thought I have is how can you free the memory used by a global variable if it isn't cleared after the connection. This could potentially use up a fair amount of memory if they are not cleared when they are no longer needed.

when needed you can use

{if|{.length|#x.}> xxxxxxx|{:{.set|#x|.}:}.}

It is possible to define a special macro for these variables:
{.set max length|#x|xxxxxxx.}

hfs.events

[start]
{.set max length|#x|20.}

[request]
{.set append|#x|abcdefghijklmnopqrstuvwxyz.}
{.add to log|#x={.^#x.}.}

in the log you can see always with this example
#x=abcdefghijklmnopqrst

[rejetto]

you can just {.set|#x|.}

from next build you can also avoid the second pipe {.set|#x.}

[Mars]

thanks, but is it possible to manage the max length?

[rejetto]

at the moment i don't see the need for a variable limit management.
you may eventually make an alias using {.set.} and {.substr.}

why are you so worried about length?

[bacter]

one consideration about 'max length':

If somebody is worried about the maximum length, i think it is more secure to take cautions before appending : {.if|>|{.length|{.^#x.}.}|nnnn|{:{.do some garbage collection on #x.....}:}.}

Cutting simply the end of a stored list without error message may lead to strange or bad behaviour of a template or an event! And also if we log the result to the logfile or use a serverside error-popup, it would normally be late to detect the problem, if you are not sitting there starring at the log!

[Mars]

 

And what think of of this formulation:

[start]
{.set max length|#x|xxx.}

[request]
{.set|#x|%url%{.^crlf.}{.^#x.}.}

[read_list]
{.^#x.}

The variable #x never exceeds xxx characters and refresh is assumed with the last informations

[bacter]

mars, your 'garbage-collection' with 'max-length' may work for secuential lists where only the most recent information is of interest. But imagine other examples where we need random access to the elements of the list.

Here is goes one example:

If I collect in the error-section [unauthorized] the login attempts with

{.if|{.is subtring|~login|%url%.}|{:{.append|loginattempts.txt | [%ip%:%now%].}:}.}

I could do this with new static vars. But as the list grows, I have to clean up the list with IP when:
a) user logs in
b) user is banned if he has more than n attempts
c) every hour i clean up IP's with attempts older than one hour.

Normally, this list is very short, but if someone tries to crack passwords using a proxy, the list can grow a lot and stripping the list with max length would not work, as wanted data can get lost.

Anyway, if yoy find max length useful, i have nothing against it, as long it's optional to set a length. 

Another question (as you use a [start] section):

This 'static' vars will be saved when HFS is shut down and reloded when HFS restarts? Or do we need to write some macros to save and reload the #vars of interest?

[Mars]

This 'static' vars will be saved when HFS is shut down and reloded when HFS restarts? Or do we need to write some macros to save and reload the #vars of interest?

To my knowledge, the static variables are protected only during the functioning of hfs, and will be useful to pass on information of a session user to the other one, but in that case, the attention on the conflicts of writing during two rival sessions.

I hope that rejetto planned a system of temporary blocking in writing of the static variables in case a writing is in the course of work.

Thus in the case of bacter, it will be necessary to save  the data in an extern in one or several files individual for every variable:


method 1: with one file

[start]
{.load|filename|#all.}
{.from table|#all|#x.}
{.from table|#all|#y.}
{.from table|#all|#z.}
.....
[quit]
{.set table|#all|#x={.^#x.}.}
{.set table|#all|#y={.^#y.}.}
{.set table|#all|#z={.^#z.}.}
........
{.save|filename|#all.}

every static var does not contain any sign '='

method 2: one file by static variable

[start]
{.load|#x.txt|#x.}
{.load|#y.txt|#y.}
{.load|#z.txt|#z.}
.......
[quit]
{.save|#x.txt|{.^#x.}.}
{.save|#y.txt|{.^#y.}.}
{.save|#z.txt|{.^#z.}.}
........

the same method with 'for each' macro

[start]
{.for each|temp|x|y|z|...|{:{.load|{.^#temp.}.txt|{.^#temp.}.}:}.}
[quit]
{.for each|temp|x|y|z|...|{:{.save|{.^#temp.}.txt|{.^#temp.}.}:}.}

Here we are, I finished and I hope to have made no error of script

[rejetto]

if i need to treat some variables with a max of 1MB, i can make a
[special:alias]
limited set=set|$1|{.cut|-1000000||$2.}

this will keep only latter 1MB, considering you are appending. If you are prepending instead
limited set=set|$1|{.cut||1000000|$2.}

[rejetto]

there are some commands that are likely to be used on large variables.
like cut, set, set append.
i think i will work to make them optionally work directly on variables.
like i did for "length", and "var length".
but creating new commands (as i did for "length") for every variant is not good. i will use named parameters instead.
you can suggest other commands if you want.