MHonArc v2.5.0b2 -->
emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: CAP Channels
Friends -
Until now most of our work has focused on the CAP alert message
format itself. But building a demonstration CAP 0.9 source has led
me to experiment with an idea developed by Robert Bunge and Eliot
Christian about one way to move CAP messages around.
Many CAP transmissions will occur in "push" mode, of course...
possibly using SOAP messaging over the Internet, or perhaps some sort
of data broadcast. But sometimes a provider of CAP traffic may want
simply to post all its current messages on a web server... to enable
catch-up by a client that's just been turned on, for example... or to
support polling clients behind firewalls and/or with dynamic network
addresses (both of which make push more difficult)... or just to
avoid the costs of creating and maintaining explicit subscription
records for a push service.
In such arrangements a list of current messages must be visible to
the clients. In early prototypes we posted a simple text list of
filenames... basically just a directory listing. Later experimenters
used an RSS file as an index to the current messages... but RSS was
designed with HTML content in mind and doesn't strike me as an
entirely comfortable fit here (although my mind remains open about
that).
So what I'm testing now (see
<http://www.edis.ca.gov/cap_0.9/index.xml>) is an RSS-like index file
customized for indexing operational XML messages. A client can
retrieve this "channel" index and determine which messages, if any,
are a) new to that client, and b) not yet expired. Then it can
retrieve those messages for further evaluation and use.
A few random notes about this arrangement:
* An unlimited number of sources and devices could expose some or all
of their current state in the form of channels, either to the general
public or (perhaps using HTTPS with authentication) to a restricted
community of viewers.
* For security and to reduce local network traffic some sources might
choose to publish their channels via off-site servers (as California
does for EDIS.)
* The channel index can reference messages from other servers and
sources, so a specialized channel could link to selected messages
from one or several sources... e.g., as a channel of messages
targeted to a particular region, or of a particular type. (RSS is
used that way frequently to aggregate Web content according to some
particular editorial principal.)
* The <item> element includes the source and identifier of the
message, which together form a unique ID for that message (at least
in the case of CAP)... so a client looking at multiple channels could
resolve any duplications it encountered.
* The <item> includes a <format> element populated with the default
namespace for the target document... so a channel could expose
multiple types of XML messages, not just CAP alerts. (Of course, a
specialized channel client could filter out all but a particular
format.)
* An <item> can refer to another <channel>, so a "channel of
channels" might provide a basic means of discovering data sources.
(Of course, "recursive" channel clients would want to implement loop
detection, just in case.)
Again, I want to stress that the channel concept doesn't preclude any
other dissemination options or architectures... but for simple
implementations it may be a convenient and flexible approach.
Your thoughts?
- Art
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]