Also rename them to describe better what they do.
ConfigFile:
cf_filename -> filename
cf_next -> next
cf_entries -> items
ConfigEntry:
ce_fileptr -> file
ce_varlinenum -> line_number
ce_fileposstart -> file_position_start
ce_fileposend -> file_position_end
ce_sectlinenum -> section_linenumber
ce_varname -> name
ce_vardata -> value
ce_cond -> conditional_config
ce_entries -> items
ce_next -> next
ce_prevlevel -> parent
Also add doxygen docs for both structs.
depending on the module load order. Reported by k4be.
Changes:
* Websocket hooks:
* Input should be run first
* Output should be run last
* Labeled-response also had various hook priorities wrong
* Pre command should be run near-first
* Post command should be run near-last
* Close connection (does the flush) should be run near-last
* Packet should be run near-last
This so I - and others - don't constantly have to wonder whether the client
is called sptr, cptr or acptr in a simple routine.
Insane --> 212 files changed, 6814 insertions(+), 6945 deletions(-)
Couldn't just mass-replace of course since there are places where there
are multiple clients involved. So had to check each function.
Also renamed some 'acptr' to 'target' and such.
I will write a page with new style rules later.. but in short if there is
only 1 client involved it will now be called 'client'.
'sptr' is sufficient and in most cases the only one you should care about.
Should you need it, you can access sptr->direction in cases where you
need the old information (usually only for some sendto_* functions
and some protoctl checks), so 'cptr' was redundant too.
[!] This change likely introduces some bugs. This was many hours of work.
I only cut some corners in 4 functions, which will be fixed at a later
stage..... yes, more major changes to come.
On the plus side, I likely fixed some bugs in the process. Situations
where cptr vs sptr usage was incorrect. Eg using cptr->name (near server)
when sptr->name should be used (the actual source server), etc....
In such a case we refuse to run since the consequences are too big.
(Actually I may change the non-UTF8 channel warning to an error as well,
right now it isn't.. simply because I cannot read a certain setting)
From both the non-UTF8 channel and user warning/error, we now refer to:
https://www.unrealircd.org/docs/WebSocket_support#websockets-and-non-utf8
which contains a bit more detailed information as to the WHY.
how you use websockets in the configuration file:
In addition to loading the websocket module you now ALSO have to mark
specific listen blocks with listen::options::websocket, and you have
to specify a type as well. Example:
listen {
ip *;
port 1234;
options {
websocket { type binary; }
}
}
The type 'text' is compatible with kiwi although this is currently
completely untested. Also I should add something to the release notes
about this change. Tomorrow...
MOD_UNLOAD. And MOD_HEADER(xyz) is now MOD_HEADER even without ()
since this isn't a function, really.
To make things understandable I added the following to the
developer section of the release notes:
* The module header is now as follows:
ModuleHeader MOD_HEADER
= {
"nameofmodule",
"5.0",
"Some description",
"Name of Author",
"unrealircd-5",
};
There's a new author field, the version must start with a digit,
and also the name of the module must match the loadmodule name.
So for example third/funmod must also be named third/funmod.
* The MOD_TEST, MOD_INIT, MOD_LOAD and MOD_UNLOAD functions no longer
take a name argument. So: MOD_INIT(mymod) is now MOD_INIT()
aChannel to Channel, and some more. Third party module coders will
love this. But.. it makes things more logical and the doxygen output
will look more clean and logical as well.
(More changes will follow)
and remove old dependency field (never used, was always NULL,
broken since 3.2.x)
I'll add some constraints later on things like names and versions.
IOTW: more changes to follow, don't mass update your own mods yet.
This also includes buffer modifications to have a larger read buffer
and IRCv3 implementations (partial or not) for:
labeled-response, msgid, server-time, batch and account-tag.
As said, it is the initial and partial implementation.
There are still various FIXME's and TODO's, the API of various
functions may still change (actually that is true for the next
months, even) and some stuff is currently in the core that will
be moved to modules.
so you can use IRC directly from HTML5/JS. It is still considered experimental
but feel free to test it out. To do so, add this to your unrealircd.conf:
loadmodule "websocket";
This module was sponsored by Aberrant Software Inc.
k4be