Rename hooks in docs

doc/developers-guide/Hooks-and-handlers.md

@@ -26,7 +26,7 @@ I.e. if `mod_offline` was not available, the code would simply crash; if it was
 To avoid that coupling and also to enable other ([possibly yet to be written](#sidenote-code-yet-to-be-written)) code to carry out some action at this particular moment, `ejabberd_sm` calls instead:
 
 ```erlang
-mongoose_hooks:offline_message_hook(Acc, From, To, Packet);
+mongoose_hooks:offline_message(Acc, From, To, Packet);
 ```
 
 `mongoose_hooks` is a module which serves as an API for calling hooks in the server. All such modules are placed in `src/hooks`.
@@ -37,7 +37,7 @@ This means that there is some degree of coupling still - but this time between t
 The extra level of indirection introduced by this call gives the flexibility to determine at runtime what code actually gets run at this point.
 This depends on which handlers are registered to process the event.
 
-`offline_message_hook` is the name of the hook (in other words of the event that is being signalled);
+`offline_message` is the name of the hook (in other words of the event that is being signalled);
 `Acc` is the [Accumulator, described later](#using-accumulators);
 `From`, `To` and `Packet` are the arguments passed to the handler, just as they would in case of the function being called directly.
 
@@ -86,10 +86,10 @@ If a Mongoose accumulator is passed to a hook, handlers should store their retur
 * If the value is to be passed on to be reused within the current processing context, use `mongoose_acc:set(Namespace, Key, Value, Acc)`.
 * If the value should be passed on to the recipient's session, pubsub node etc. use `mongoose_acc:set_permanent(Namespace, Key, Value, Acc)`.
 
-A real life example, then, with regard to `mod_offline` is the `resend_offline_messages_hook` run in `mod_presence`:
+A real life example, then, with regard to `mod_offline` is the `resend_offline_messages` hook run in `mod_presence`:
 
 ```erlang
-Acc1 = mongoose_hooks:resend_offline_messages_hook(Acc, Jid),
+Acc1 = mongoose_hooks:resend_offline_messages(Acc, Jid),
 Rs = mongoose_acc:get(offline, messages, [], Acc1),
 ```
 
@@ -122,7 +122,7 @@ It is decided when creating a hook and can be checked in the `mongoose_hooks` mo
 
 ## Registering hook handlers
 
-In order to store a packet when `ejabberd_sm` runs `offline_message_hook`, the relevant module must register a handler for this hook.
+In order to store a packet when `ejabberd_sm` runs `offline_message`, the relevant module must register a handler for this hook.
 To attain the runtime configurability the module should register the handlers when it's loaded and unregister them when
 it's unloaded.
 That's usually done in, respectively, `start/2` and `stop/1` functions.
@@ -133,10 +133,10 @@ gen_hook:add_handlers(hooks(HostType)),
 ```
 and the `hooks/1` function returns a list of tuples describing hook handlers, like:
 ```erlang
-{offline_message_hook, HostType, fun ?MODULE:inspect_packet/3, #{}, 50}
+{offline_message, HostType, fun ?MODULE:inspect_packet/3, #{}, 50}
 ```
 
-It is clearly visible that the handler `inspect_packet` is added to the `offline_message_hook`.
+It is clearly visible that the handler `inspect_packet` is added to the `offline_message` hook.
 
 `HostType` is the one for which the handler will be executed.
 In the case of statically defined domains, it is the same as the host, as configured in the [`general.hosts` section](../configuration/general.md#generalhosts).

doc/developers-guide/Stanza-routing.md

@@ -57,7 +57,7 @@ If the check passes, the next step is to call the handler associated with the co
 
 `ejabberd_sm` determines the available resources of the recipient, takes into account their priorities and whether the message is addressed to a particular resource or a bare JID.
 It appropriately replicates (or not) the message and sends it to the recipient's C2S process(es) by calling `mongoose_c2s:route/2`.
-In case no resources are available for delivery (hence no C2S processes to pass the message to), `offline_message_hook` is run.
+In case no resources are available for delivery (hence no C2S processes to pass the message to), the `offline_message` hook is run.
 
 As Bob has one online session, the message is sent to the C2S process associated with that session.
 

doc/developers-guide/hooks_description.md

@@ -130,7 +130,7 @@ These hooks are handled by the following modules:
 ## `offline_message_hook`
 
 ```erlang
-mongoose_hooks:offline_message_hook(Acc, From, To, Packet)
+mongoose_hooks:offline_message(Acc, From, To, Packet)
 ```
 
 `ejabberd_sm` runs this hook for each message which cannot be delivered, because no resource (i.e. device or desktop client application) of its recipient is available online for delivery.
@@ -212,7 +212,7 @@ This is the perfect place to plug in custom security control.
 * amp_check_condition
 * amp_determine_strategy
 * amp_verify_support
-* anonymous_purge_hook
+* anonymous_purge
 * auth_failed
 * c2s_stream_features
 * can_access_identity
@@ -235,7 +235,7 @@ This is the perfect place to plug in custom security control.
 * filter_pep_recipient
 * filter_room_packet
 * filter_unacknowledged_messages
-* forbidden_session_hook
+* forbidden_session
 * foreign_event
 * forget_room
 * get_key
@@ -273,10 +273,10 @@ This is the perfect place to plug in custom security control.
 * mod_global_distrib_known_recipient
 * mod_global_distrib_unknown_recipient
 * node_cleanup
-* offline_groupchat_message_hook
-* offline_message_hook
+* offline_groupchat_message
+* offline_message
 * packet_to_component
-* presence_probe_hook
+* presence_probe
 * privacy_check_packet
 * privacy_get_user_list
 * privacy_iq_get
@@ -289,7 +289,7 @@ This is the perfect place to plug in custom security control.
 * remove_domain
 * remove_user
 * reroute_unacked_messages
-* resend_offline_messages_hook
+* resend_offline_messages
 * room_exists
 * room_new_affiliations
 * room_packet
@@ -309,16 +309,16 @@ This is the perfect place to plug in custom security control.
 * s2s_stream_features
 * session_cleanup
 * session_opening_allowed_for_user
-* set_presence_hook
+* set_presence
 * set_vcard
 * sm_filter_offline_message
-* sm_register_connection_hook
-* sm_remove_connection_hook
+* sm_register_connection
+* sm_remove_connection
 * unacknowledged_message
 * unregister_subhost
-* unset_presence_hook
+* unset_presence
 * update_inbox_for_muc
-* user_available_hook
+* user_available
 * user_open_session
 * user_ping_response
 * user_receive_iq

doc/developers-guide/mod_muc_light_developers_guide.md

@@ -84,7 +84,7 @@ There are 2 test suites and one helper module in `big_tests/tests`.
 
 ## Hooks handled by this extension
 
-* `offline_groupchat_message_hook` handled by `mod_muc_light:prevent_service_unavailable/3`
+* `offline_groupchat_message` handled by `mod_muc_light:prevent_service_unavailable/3`
 
 Prevents the default behaviour of sending `service-unavailable` error to the room when a groupchat message is sent to an offline occupant.
 

doc/operation-and-maintenance/MongooseIM-metrics.md

@@ -73,7 +73,7 @@ As a result it makes more sense to maintain a list of the most relevant or usefu
 
 | Name | Type | Description (when it gets incremented) |
 | ---- | ---- | -------------------------------------- |
-| `[HostType, anonymous_purge_hook]` | spiral | An anonymous user disconnects. |
+| `[HostType, anonymous_purge]` | spiral | An anonymous user disconnects. |
 | `[HostType, disco_info]` | spiral | An information about the server has been requested via Disco protocol. |
 | `[HostType, disco_local_features]` | spiral | A list of server features is gathered. |
 | `[HostType, disco_local_identity]` | spiral | A list of server identities is gathered. |
@@ -82,15 +82,15 @@ As a result it makes more sense to maintain a list of the most relevant or usefu
 | `[HostType, disco_sm_identity]` | spiral | A list of user's identities is gathered. |
 | `[HostType, disco_sm_items]` | spiral | A list of user's items is gathered. |
 | `[HostType, mam_lookup_messages]` | spiral | An archive lookup is performed. |
-| `[HostType, offline_message_hook]` | spiral | A message was sent to an offline user. (Except for "error", "headline" and "groupchat" message types.) |
-| `[HostType, offline_groupchat_message_hook]` | spiral | A groupchat message was sent to an offline user. |
+| `[HostType, offline_message]` | spiral | A message was sent to an offline user. (Except for "error", "headline" and "groupchat" message types.) |
+| `[HostType, offline_groupchat_message]` | spiral | A groupchat message was sent to an offline user. |
 | `[HostType, privacy_updated_list]` | spiral | User's privacy list is updated. |
-| `[HostType, resend_offline_messages_hook]` | spiral | A list of offline messages is gathered for delivery to a user's new connection. |
+| `[HostType, resend_offline_messages]` | spiral | A list of offline messages is gathered for delivery to a user's new connection. |
 | `[HostType, roster_get_subscription_lists]` |  spiral | Presence subscription lists (based on which presence updates are broadcasted) are gathered. |
 | `[HostType, roster_in_subscription]` | spiral | A presence with subscription update is processed. |
 | `[HostType, roster_out_subscription]` | spiral | A presence with subscription update is received from a client. |
 | `[HostType, sm_broadcast]` | spiral | A stanza is broadcasted to all of user's resources. |
-| `[HostType, unset_presence_hook]` | spiral | A user disconnects or sends an `unavailable` presence. |
+| `[HostType, unset_presence]` | spiral | A user disconnects or sends an `unavailable` presence. |
 
 ### Presences & rosters