358
edits
Ommina
Joined 21 September 2007
→Getting Notifications
No edit summary |
|||
| Line 22: | Line 22: | ||
With this method, the client contacts the server at some interval (no more than once every 20 minutes) to see if there are new file notifications waiting. If there are, the client can the get further details of the files in question. This is analogous to checking an email server every half hour to see if new email has arrived. | With this method, the client contacts the server at some interval (no more than once every 20 minutes) to see if there are new file notifications waiting. If there are, the client can the get further details of the files in question. This is analogous to checking an email server every half hour to see if new email has arrived. | ||
Its principal advantage is that it is easy to design and code. Blocking sockets are sufficient as the client can expect the reply received to correspond with the command sent. | |||
The disadvantage of this approach is that it introduces a delay and some uncertainty in receiving notifications. If, for example, the user clears the notification on the website before the client collects it, the client will not learn of the new file. Similarly, if the user does not dismiss notifications via the site, the client will have an increasing amount of stale data to work though. Finally, notifications cleared by the client also clears them from the website, so users will need to be made aware of what is going on. | The disadvantage of this approach is that it introduces a delay and some uncertainty in receiving notifications. If, for example, the user clears the notification on the website before the client collects it, the client will not learn of the new file. Similarly, if the user does not dismiss notifications via the site, the client will have an increasing amount of stale data to work though. Finally, notifications cleared by the client also clears them from the website, so users will need to be made aware of what is going on. | ||
| Line 34: | Line 34: | ||
{{eyecatch|NOTE|The ID supplied by NOTIFYLIST will be the ID of the affected notification type. Since, at present, only the anime type is supported, this value is always an aid. In the future, it may represent a group or producer ID. In these cases, the str type value | {{eyecatch|NOTE|The ID supplied by NOTIFYLIST will be the ID of the affected notification type. Since, at present, only the anime type is supported, this value is always an aid. In the future, it may represent a group or producer ID. In these cases, the str '''type''' value will indicate what entity the ID represents.}} | ||
| Line 50: | Line 50: | ||
* Use NOTIFYGET to receive a notification, suppling the relid provided by NOTIFICATION (NOT the packet ID) | * Use NOTIFYGET to receive a notification, suppling the relid provided by NOTIFICATION (NOT the packet ID) | ||
* Use NOTIFYACK to acknowledge a notification, suppling the relid provided by NOTIFICATION (if desired) | * Use NOTIFYACK to acknowledge a notification, suppling the relid provided by NOTIFICATION (if desired) | ||
* Use UPTIME (with an interval between 30 and 35 minutes) to keep login session valid | |||
It is probably a good idea to use tags to separate NOTIFICATIONs from the other communication. NOTIFICATIONs will '''never''' have tags. | It is probably a good idea to use tags to separate NOTIFICATIONs from the other communication. NOTIFICATIONs will '''never''' have tags. | ||
=== PUSH: UDP Notification Registration === | === PUSH: UDP Notification Registration === | ||
With this command you can register your client as an observer for anidb notification events for the current user. If you are registered for one or more event types the anidb server will send an UDP packet (format see below) on each change which affects the current user. The UDP packet is sent to the ip and port from which the AUTH command was recieved. | With this command you can register your client as an observer for anidb notification events for the current user. If you are registered for one or more event types the anidb server will send an UDP packet (format see below) on each change which affects the current user. The UDP packet is sent to the ip and port from which the AUTH command was recieved. | ||