Ticket #322 (new enhancement) — at Version 4

Opened 4 years ago

Last modified 4 years ago

Interface for Notification Service

Reported by: dread Owned by: dread
Priority: blocker Milestone: v1.1
Component: ckan Keywords:
Cc: Repository:
Theme:

Description (last modified by dread) (diff)

Use cases

  • Register for package changes
  • Register for all revisions
  • Notified of a package change
  • Notified of a revision
  • Deregistration
  • Configuration of port in pylons config

Design

  • Default port: 5672 (standard for AMQP)
  • Exchange name: 'ckan'
  • Exchange type: topic exchange (most flexible)
  • Routing keys: (see below)

Routing detail

Routing key format: "OBJ_TYPE" (NB tags should be identified by their name, not ID)

Example routing keys

  • 'package' - Package edited/created
  • 'resource' - Resource edited/created
  • 'revision' - Any change

Example queue bindings that clients may use:

  • * - no filtering - client receives all notifications
  • package - only changes to packages
  • revision - all revisions

Versioning

Since message payloads will be tied into the REST Entities, it makes sense to join up with the REST versioning. This could be achieved by providing new exchanges called 'ckan-1.1' perhaps?

Documentation

  • How to use
  • simple example of an external client?

Change History

comment:1 Changed 4 years ago by dread

  • Description modified (diff)

comment:2 follow-up: ↓ 3 Changed 4 years ago by pudo

This looks very reasonable. Maybe we should have a webhooks client as a simple demo for this?

comment:3 in reply to: ↑ 2 Changed 4 years ago by pudo

Replying to pudo:

This looks very reasonable. Maybe we should have a webhooks client as a simple demo for this?

c.f. #327

comment:4 Changed 4 years ago by dread

  • Description modified (diff)
Note: See TracTickets for help on using tickets.