If the timer activates a bit early then a task might be just a few
seconds short of being allowed to run. This would run such a task rather
than wait another hour.
The value 0.5% chosen so that a weekly task does not run an entire hour
earlier than last time.
There was an off-by-one in the modulo calculation. Switching to a plain
old array-table makes the apparent size of the queue wrong, but since
some of the queue may not be available this is likely for the best.
Meant to be used in mod_smacks for XEP-0198
Meant to have a larger virtual size than actual number of items stored,
on the theory that in most cases, the excess will be acked before needed
for a resumption event.
Eventually the goal is to have daily tasks run while there is little
activity, but that will vary with the server and the usage patterns of
its users. This is a start anyway.
A number of modules now have periodic tasks that need to run, e.g. for
cleaning out old messages or files. This has highlighted a need for
coordinating and optimizing scheduling of such tasks.
Turns falsy values into nil instead of nothing, which ensures this
function always has 1 return value, or table.insert({}) complains. Would
still happen on some unexpected input, but that's actually a good thing.
So the problem is that xmlns is not inherited when building a stanza,
and then :get_child(n, ns) with an explicit namespace does not find that
such child tags.
E.g.
local t = st.stanza("foo", { xmlns = "urn:example:bar" })
:text_tag("hello", "world");
assert(t:get_child("hello", "urn:example:bar"), "This fails");
Meanwhile, during parsing (util.xmppstream or util.xml) child tags do
get the parents xmlns when not overriding them.
Thus, in the above example, if the stanza is passed trough
`t = util.xml.parse(tostring(t))` then the assert succeeds.
This change makes it so that it leaves out the namespace argument to
:get_child when it is the same as the current/parent namespace, which
behaves the same for both built and parsed stanzas.
So extract_value() takes an XML tag and details about which part we're
interested in and returns that.
Factoring this out will help with array implementation since this will
be common behavior.
Now it gets the text, attribute or name first, then turns it into
whatever the schema wants. This should be easier to further factor out
into preparation for array support.
