Skip to content

Latest commit

 

History

History
68 lines (50 loc) · 3.62 KB

README.md

File metadata and controls

68 lines (50 loc) · 3.62 KB
Raw

Mimisbrunnr

(Pronounced "mims-brun-er")

Build Status Dependency Updateer codecov.io Go Report Card Quality Gate Status Apache V2 License GitHub Release

Summary

Mimisbrunnr provides device level event delivery. It registers a webhook to Caduceus. Upon receiving Caduceus events, Mismisbrunnr fans out those events to any current device registrations it has. Mismisbrunnr has an API to allow consumers to register to receive events for a specific device. This registration object is called a norn.

Table of Contents

Code of Conduct

This project and everyone participating in it are governed by the XMiDT Code Of Conduct. By participating, you agree to this Code.

Details

This service is still being developed, so some details are currently unknown.

API

  • POST on /norns - creates the norn, stores it in argus, and returns norn id; if a norn with the same destination and device id exists, it updates it as long as the client owns it)
  • PUT on /norns/<id> - updates an existing norn, as long as the client owns it
  • DELETE on /norns/<id> - deletes the norn from argus, as long as the client owns it
  • GET on /norns - returns a list of norns that the client owns
  • GET on /norns/<id> - returns the norn attached to the id given, as long as the client owns it
  • POST on /events - mimisbrunnr validates the event and possibly sends it to applicable norns

Norn

A consumer will request events from a particular device to be sent to a destination. The request is called a Norn and MUST contain the following information:

  • deviceID
  • destination and required information to successfully send the message such as auth or access keys.
  • duration for how long to listen to the event. (details of this still being discussed)
  • a filter function to determine if the event should be sent. Note: not a part of the MVP.

For the remainder of that duration, events will be delivered to the destination specified with best effort.(aka not guaranteed)

Additional Design Decisions:

  • All incoming and outgoing events must be WRPs
  • There should be a maximum duration a norn can last, which will be configurable in the yaml.
  • Destinations for the MVP will only support http and sqs
  • An internal buffering system will be used, one per norn.
  • No two norns will share the exact same device ID and destination.
  • If the channel for the destination is full, the destinations will be notified and message will be dropped.

Install

Add details here.

Contributing

Refer to CONTRIBUTING.md.