Project Management

Design

• The Models: The table definitions go are in modules/s3db/cap.py. Place some functions which will help in the creation, sending and receiving of CAP XML files in s3msg module where it might best fit.
  • A detailed description of the data model is here: ​https://docs.google.com/spreadsheet/ccc?key=0AiLVG3CYfknsdGljMXNQejNWSURnVHZYYnMySERzdHc
  • The module dependency graph is explained here: [Tharindu - insert URL to doc]
• The GUI
  • index: A map and a table of alerts sortable by the various fields of an alert. Clicking on a row on the table centers the map to the <Area> associated with the alert.
  • profiles:
    • index: View a listing of templates (We should ship some country-specific profiles by default in Eden since this is recommended)
    • edit & create: Editing / creating a profile. This should allow for specification of constraints for each field of the cap message.
  • templates:
    • index: View a listing of all templates grouped by their pertinent profiles.
    • edit & create: Allow users to create templates: This will allow for creating multiple <info> elements with placeholders for canned inputs such as [AREA] [SEVERITY] etc.which will then be substituted to produce text consumable via various media like SMS and IVR
  • create alert: A map with ability for easy input of polygons and circles, A drop-down for picking profiles and templates to use. A way to specify recipients for restricted alerts.
  • Reference and mockups: http://eden.sahanafoundation.org/ticket/1026

Implementation

• GSoC 2012 project: Event/2012/GSoC/CAPBroker

References

• ​CAP 1.2 Specification

Notes

Common Alerting Protocol:

Originating CAP alerts is one need, receiving them and using them to actuate alerting systems, be they SMS drivers or sirens or whatever is another. Another is a message broker that can interoperate with the commercial boxes. Authentication systems are also a factor, especially where cross-jurisdictional reciprocity is required

Ideally the CAP XML should be signed end-to-end, especially in a federated system where there's more than one authority running servers/aggregators. Our current implementations sign the alerts at the originating server, so they're at least traceable to the source server but not necessarily the individual operator. Current servers check integrity when they get a message from another server, but there isn't a regional PKI.

• ​http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.html
  • Use an XSLT
• Subset of EDXL-DE: ​http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf
  • Use another XSLT
  • ​http://code.google.com/p/pyedxl/source/browse/trunk/edxl/edxl.py
  • ​http://edxlsharp.codeplex.com
  • SQL schema: ​http://wiki.sahanafoundation.org/doku.php/wiki:user:edxl_discussion#proposed_sahana_edxl-de_database_implementation
• ​http://talksahana.com/2009/03/04/firefox-browser-cap-alerting-plugin-sahana-idea-for-gsoc2009/
• Sahana CAP/EDXL Broker specification - ​http://lirneasia.net/wp-content/uploads/2009/05/Sahana-CAP-Msg-Mod-v0.2.pdf

Wireframe (ported to eden)

• The wireframe built using Python and Eden frameworks.​ The code is here. Anyone can use this as the basis to continue the CAP Broker developments.
• This ticket contains some of the screen shots and initial GUI layouts with some descriptions.

---

BluePrints