| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Many of these fall into a few categories:
- util.cache size, must be >= 1
- byte or item counts that logically can't be negative
- port numbers that should be in 1..0xffff
|
| |
|
|
| |
Improves readability ("1 day" vs 86400) and centralizes validation.
|
| | |
|
| |
|
|
| |
See bd9e006a7a74
|
| |
|
|
|
| |
This message was misplaced in c4599a7c534c when the @type and @host
check was introduced.
|
| |
|
|
|
|
|
|
| |
These are RECOMMENDED in XEP-0215 so most likely a mistake if they are
left out.
Of the two REQUIRED fields, 'host' falls back to module.host and 'type'
rejects the whole item.
|
| |
|
|
|
|
|
|
| |
Along with the previous commit, allows building the XML thing yourself,
should you wish to send it yourself or use it in a different context than
an iq reply.
API change: The 'reply' is removed from the event.
|
| |
|
|
|
| |
This way you get the _prepared_ services and don't have to do that mapping
yourself.
|
| |
|
|
| |
Please don't be accidentally quadratic.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Because during startup, if all items are provided by a different module
(e.g. mod_turn_external) then this would log a scary warning even if
everything is fine after that other module has been loaded.
This way, any persistent problematic state is reported in the console.
Errors with individual items should still be reported by prepare().
Now, if you load mod_external_services alone without configuring any
services, no error or warning is reported in the log, but maybe that's
not so bad with it reported in the console.
|
| | |
|
| |
|
|
|
|
|
|
| |
This ensures that problems with entries added other modules, e.g.
mod_turn_external, are reported on startup. However, this depends on
load order and whether a `module:depends()` call comes before the
`module:add_item()` call. A followup commit will do something about
that.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While writing developer documentation it became obvious that i was silly
to have one item format for config and items API, and another format for
the event API.
Then there's the stanza format, but that's a common pattern.
This change reduces the possible input formats to two and allows other
modules the benefit of the processing and validation performed on items
from the config.
|
| |
|
|
|
| |
This is especially targeted at services added via the items API. More
involved credential generation should use the event hook.
|
| |
|
|
|
|
| |
Not sure what algorithms might fit here. Separation makes some sense.
This is also a preparation for having a callback. (See next commit)
|
| | |
|
| |
|
