| Overview |  |
Introduced in: 27 Apr 2006 by Fredrik Thulin <ft@it.su.se>
Behaviours: gen_server.
Authors: Fredrik Thulin (ft@it.su.se).
Handle a SUBSCRIBE dialog (RFC3265).
These gen_servers are dialog controllers for dialogs established by SUBSCRIBE requests sent to the YXA application 'eventserver'.
Each time they receive a SUBSCRIBE (a request to refresh the subscription) they ask the event package module what to do.
Whenever there is a request to send out NOTIFYs on the dialog, these processes ask the event package to supply the body of the NOTIFY request etc.
Terminology :
Presentity: The 'presenter' of presence information. This is either {user, User} when the Request-URI of the SUBSCRIBE was an AOR of one of our users, or {address, AddressStr} when it was not.
Subscriber: The entity subscribing to someones presence. Currently, this is always one of our users username, since we only allow subscriptions from people we can authenticate.
If we do bidirectional subscribe, the subscriber will be the presentity for the SUBSCRIBE we send out.
TODO :
* Implement NOTIFY rate limitingstate() = #state{}
no description
| handle_call/3 | |
| send_notify/1 | Request that the subscription dialog controller Pid sends out a NOTIFY. |
| start/5 | Starts the server, if the event package in question says that the preconditions for a subscription are met. |
handle_call() -> term()
send_notify(Pid) -> term()
returns: result of gen_server:cast/2
Request that the subscription dialog controller Pid sends out a NOTIFY. No NOTIFY will be sent out if it matches the last NOTIFY sent on that subscription.
start(Request, YxaCtx, PackageM, PackageS, Subscriber) -> Pid
Starts the server, if the event package in question says that the preconditions for a subscription are met.
Generated by EDoc, Oct 17 2007, 16:48:12.