Plugin Design

[gbprz]

How did the Concerto v1 EMS plugin work? Did an admin actually have to enter a message or does the system get the alerts from another location? I know that Marvin mentioned CAP or the Common Alerting Protocol as the standard for agencies like FEMA in the US. For RPI, how did public safety send alerts?

Right now all I have done is created a button on the screen show page that links to the plugin's form for creating a new alert message. This message would then need to be displayed on every screen in deployment. It might be better to create a new hook in Concerto on the screen index page so the emergency button is easier to find.

[mfrederickson]

I believe that it was just a special feed that superceded all other feeds, and none of the content was pulled from anywhere-- it was all manually entered. The CAP thing was from someone else on the forum, but it was a great idea.

[augustf]

Though there's considerably more complexity behind the scenes, the Concerto 1 EMS existed to do one thing -- take emergency alerts from the Public Safety RSS feed and override each screen's feed subscription to show a piece of content with the RSS feed text displayed on a red slide.

Obviously, a more generalized tool like this should have the ability to create an alert (and output it via RSS/JSON) as well as the ability to draw it from something like an RSS feed.

[augustf]

@mfrederickson Just to clarify, in the RPI instance, there wasn't actually a manual input step for us. It might have been something external to the codebase, but the Public Safety RSS feed became a piece of content automatically.

[mfrederickson]

Wow, that was far more than I saw in php stuff that I looked at. Cool.

[augustf]

Yeah-that last bit of getting the RSS over may well have been some RPI specific code or just a cron. @bamnet might remember more.

[gbprz]

So, with the manual entry, should this plugin add a new content type and when alert content is submitted, can we use the content plugin's specific frontend javascript to create a box the size of the window.height and window.width that will cover the entire screen and have the message centred on the screen?

Or, when an alert is submitted, should a method be invoked in the Alert model that changes every screen's template to one that is defined by the plugin and subscribe only alert type content to this field?

Maybe a background script might be more sensible ... run a loop that sleeps every few seconds and contacts the server to see if any alerts have been posted. If so, redirect the browser to a url defined by the plugin that displays only the alert message on a red background. The script can return to the normal screen after a certain amount of time or something else ... could this possibly be integrated with Bandshell?

[augustf]

I think @bamnet is about to jump in with a more detailed account, but integration with Bandshell or an external script is probably not the way to go for the basics, as we want this to work on anything running Concerto, not just things running our custom Concerto player distro.

[bamnet]

I'd caution us against trying to become an emergency management provider of any sorts, the goal isn't really for Concerto to be the source of truth about emergencies, but to automatically consume content from another system which is. The emergency people don't want to know what Concerto is or how it exists, just that magically their alerts show up on every screen because a smart sysadmin configured it to do that once.

There are two components for this system in V1 (lets ignore audio for now):

1. A Dynamic Feed which pulls content from an RSS feed at a regular interval. There are formatting rules which make this content look extra scary, but it's still just a regular piece of content (HTML that we're shoving into a graphics field). This isn't anything special to emergencies because there was no such thing as "default" formatting for RSS feeds, you had to customize your own formatting engine using Bailiwicks each time.
2. Override logic in the code that serves the next piece of content that is always checking to see if there is content in that feed for that given field. Is there any graphical content for feed ? If Yes then serve that, else do the regular thing.

I think we should build something fairly similar for V2. A piece of content which inherits from RSS with similar properties to the emergency content that we generated in V1, it will get added and removed to a feed via the normal RSS > Dynamic Content refresh pipeline. It should be possible to inherit from RSS and replace the code that actually builds the HTML content to make it look scary (red background, etc) and have the correct emphasis... but there might be some refactoring of the RSS content to support this.

We also need to wire up hooks which allow a feed to supersede other feeds during rendering. This would allow the automatic distribution of alerts just like V1 and, if the situation warranted, the upload of a manual piece of content triggering the alert which would be supported as well.

[augustf]

@bamnet Certainly in the RPI case, there's no call for Concerto to act as an information provider, but I'm not sure that's the case for most of our potential users. I suppose these could be separate plugins, but it seems to me that many of the folks using open source Concerto are small-time deployments who in all likelihood don't have an existing EMS (and Concerto and its screens may be the EMS). In that case, having the ability to generate either graphical content or textual content on an emergency template would be very beneficial for them (and easy for us).

My initial sense is that having a plugin that offers both EMS input and output would be the best way forward overall -- unless there's a feeling that this would be systematically confusing to users in some way.

[bamnet]

That's fair I suppose. My take on that would be that the plugin would add 2 content types, in addition to those magic frontend controller overrides. EmergencyAlert could be manually created by users and builds some alarming HTML for the Graphics area. EmergencyRSS could extend RSS to build EmergencyAlerts instead of the default HTML text area content. Our Feed <-> Content Type mapping would let people prevent one or the other of those content types from being uploaded where that's undesired.

On Dec 22, 2013, at 10:56 AM, August notifications@github.com wrote:

@bamnet https://github.com/bamnet Certainly in the RPI case, there's no call for Concerto to act as an information provider, but I'm not sure that's the case for most of our potential users. I suppose these could be separate plugins, but it seems to me that many of the folks using open source Concerto are small-time deployments who in all likelihood don't have an existing EMS (and Concerto and its screens may be the EMS). In that case, having the ability to generate either graphical content or textual content on an emergency template would be very beneficial for them (and easy for us).

My initial sense is that having a plugin that offers both EMS input and output would be the best way forward overall -- unless there's a feeling that this would be systematically confusing to users in some way.

— Reply to this email directly or view it on GitHubhttps://github.com/concerto/concerto-emergency/issues/2#issuecomment-31089833 .

[gbprz]

To summarize, the plugin will create two types of EmergencyAlert content: one that inherits from Graphic and one that extends RSS. It will be up to the user to choose which fields the emergency content will show up in, just like other contents. Emergency Alert text will map to the graphics field and the emergency alert RSS will have the benefits of Dynamic Content to provide emergency updates and will map to the html text field.

Based on this, the best place to start for me would be to create the two content types and get them to render on the appropriate fields of a screen along with the other contents.

[mfrederickson]

Are we still going to need new content types for this plugin? Do we even need this plugin based on our discussion?

Based on our discussion last night during the hangout, I think the plan is to leverage all existing content types by having an emergency feed. When any content is detected on the emergency feed, then the screens will switch over to the emergency template and override all feeds with just the emergency feed. When the emergency feed is empty then the screens template and feeds will revert back to normal. So we could use the existing RSS content type to pull public safety stuff into the emergency feed.

Is that a correct understanding of the what we discussed? Would the emergency template and emergency feed be identified via the config settings?

Also, we talked about the ability to support rotating templates and even have them scheduled for certain times. So obviously the template swapping functionality would be leveraged by the EMS functionality also.

Since were planning on at some point adding scheduling to content, one would think we could have a concerto-template plugin. Then we could leverage that for controlling which template appeared on the screens, when-- we'd need a nonvisual "Template" field. The template associated with the screen via the screen model would be the default template for that screen. This template plugin could also be the one that looks for emergency content and swaps over when there is some. What do you think about that?

[mfrederickson]

Linking this discussion to concerto/concerto#808 and concerto/concerto#809

[gbprz]

I agree that this plugin might not be needed. Similar to how the first Concerto feed is created, should the Emergency Feed, Template, and Subscriptions be created in the db seeds file? Once the functionality for rotating templates is implemented, EMS content will behave like you just described.

The name Concerto Emergency might need to be reserved as a Feed name though. Maybe this can be mentioned in the wiki so if the Feed or Template is deleted, the user can set up their own again.

The template plugin idea sounds cool too. Would adding a new hook in the Frontend::ScreensController show method right after the Screen variable is created be a good way to replace the Screen.template_id? The template plugin can have the logic check to see if the Emergency Content is present, then utilize the provided hook to change the template_id.

[bamnet]

I think we should still make this happen. The template stuff is something we'll tackle, but I don't want to block testing @ RPI on it. We should be able to get a content-based approach out much quicker and iterate on it from there.

We should have a way for people to manually submit Emergency content which creates HTML which has kind=Graphic and makes the pretty red emergency content w/ background image like we had at RPI.

We should also have a way for people to create an piece of RSS content which creates these Emergency content from an RSS feed.

[mfrederickson]

@bamnet it doesn't make sense to me to spend time developing another RSS and another Text plugin when we already have those, and more (video, etc) that can still have the fancy red background by using a template with a special emergency css stylesheet included in it. Wouldn't the time be better spent on the template switching plugin? Besides, once we have the template switching plugin wouldn't those two plugins be throw-away at that point?

You also wouldn't need those two new plugins that render text content in the graphic area if you merged in the mulitple_kinds_per_field branch and had the new emergecy template's main field position accept graphics and text.

I think the concerto-template plugin would only take about a day to get done. I don;t think you'd need any hooks either because once template content was detected (explicitly or implicitly based on existence of content on the emergency feed) then the frontend js that handles the template type of content could cause a reload of the new template. (We would need the ability to not reload same content at this point so it doesn't keep reloading the same template.)

[bamnet]

I'm not sufficiently convinced that the template solution will solve the problem as adequately as the initial content-based approach because there's a lot of details we have to get right in the implementation first.

• What sort of template update interval will we support? Emergency alerts need to go out fast, we've typically relied on the fact that content is short lived to achieve this. Checking if your template is current every ~15 seconds sounds like overkill for everyone who doesn't use EMS.
• How do we handle API screens? It's not safe to assume every screen is running frontend.js, they are just talking to the endpoints that the controllers in the frontend namespace provide. As an example, the current incantation of the oft forgotten screensaver doesn't actually show a template, it just uses a full screen graphical area and knows how to render a limited subset of content.
• Are we safe to switch templates on all screens, especially those with weird templates? We'd have to test to make sure that portrait screens worked as well as the regular landscape ones.

[gbprz]

I tried two different approaches this week, both using hooks into the frontend screens controller. The first attempts to duplicate the screen variable in the setup method and change the template it uses. If this is the first time the plugin runs, it creates its own template, subscribing a reserved feed name 'Emergency Alerts'.

The second attempt simply replaces the screen variable in the setup method with a screen using the reserved name 'Emergency Screen'. The second method worked well but I am assuming the first approach will work fine too if it's given more attention. I'm not sure if either approaches are what you guys had in mind and I can rework things if I'm missing the point.

I still need to work on a more reliable way of switching back to the normal screen once the alerts expire. I made two different attempts to add hooks into the frontend screens controller and contents controller but they both seemed like overkill to check for emergency contents each time the screen seeks new content. Not sure if there is any other way though.

I know that @mfrederickson was talking about adding templates by default into the Concerto installation and he mentioned the Emergency Template. So that means the plugin won't need to create a template and can just find the correct one and replace the screen easily.

[mfrederickson]

If there is not a dedicated check (polling) from the frontend for determining when a template change is needed, then it will have to occur via an existing mechanism (through the content), or somehow via bandshell (which was deemed not an option). Since the content is getting fetched periodically anyway, I would think that this would be the way to go without increasing traffic back and forth.

This is kind of what I had in mind...

detecting a template change We could simply send another item in the hash for the content that indicated that the screen needed to reload-- just a boolean flag. This could be determined by presence of content in an emergency feed or simply a scheduled template change (functionality would need to be added to be able to schedule templates for screens). The base content class on the frontend would read this and when detected simply reload the entire page.

effecting the template change The frontend screen's setup (whether via a before filter, like you've been working on, or not), would simply use the template assigned to the screen, or the one that should be active according to a schedule, or the emergency one if content is present in the emergency feed. Reverting back to the normal template would happen automatically when the content in the emergency feed expired (or was moderated out).

sending emergency content Additionally, in the content fetching process, the normal subscription for the field would be ignored/superceded by the emergency feed's content when there is content detected in that feed.

supporting the emergency The currently designated emergency feed and the currently designated emergency template should not be deletable. Ideally you'd be able to designate them from the available selections (and store the selections in the concerto config). All screens would use the same emergency template.

Personally, I think these changes should all be made to the core of concerto. And the emergency plugin would simply be used for creating emergency content (although, imho, it would be redundant since we've pretty much got all of the possible content covered via the other content types [especially when we make the Ticker be able to save as Ticker or HtmlText]).

[mfrederickson]

Shouldn't this go into a design document in the wiki?

[gbprz]

Yea, I was thinking that earlier. Didn't want to start anything just in case I was designing it incorrectly though.

Thanks for the input. I'll add in the check for emergency contents I had earlier to reload the screen setup and consequently swap templates.

[mfrederickson]

I guess you can't comment on the wiki's like you can here. So this is a good place to work it out...

[mfrederickson]

In regards to detecting a template change concerto/concerto/pull/837 includes the code that will detect a template change and cause the screen to refresh.

[gbprz]

Awesome, thanks for the help. Do you think the Emergency Template should be created in the Concerto db seeds file, much like the default one? I know you mentioned this in an issue on the main list, but is this how it will be approached?

[mfrederickson]

No, I don't. Because every template that we decide to package with concerto as a canned template will need to be manually added. In addition to that, users that want to extract and tweak one of them wont be able to do so very easily. I think It would be better to provide a first-time template loading facility that automatically loaded them from a certain directory. That way, if a new template comes along, we just put it there. And if someone wants to copy and tweak the emergency template (for instance) they can grab the zip, change it and then load it via the template import.

[gbprz]

Okay, gotcha. How about the Emergency Alerts Feed that the plugin will check for submitted alerts from? Should that be installed by default or just explained in documentation on how to create it? I know you mentioned it should not be able to be deleted, but would this be for just regular users or should admins be unable to delete as well?

[mfrederickson]

Well, if I were designing it as a plugin, I'd have it add two config entries-- one for the emergency template (id) and one for the emergency feed (id)-- though I'd make them selectable from available options [you'd have to change the core config items form to be able to handle types of 'feed' or 'template']. I'd also prevent the deleting of these by anyone (just like even an admin can't delete the template that is in use by a screen), though I'm not sure how you'd hook in to prevent that.

So I'd have the plugin create the Emergency Feed (if it didn't exist already) and set it as the emergency feed. And I'd have it import the emergency template (if it didn't already exist) and set it as the emergency template. I'd also have a hook into the screen model's effective_template method where your code would return the emergency template if any content was found in the feed. I'd also add a hook to the frontend's contents#index and contents#show that would supercede the content with content from the emergency feed.

[mfrederickson]

TLDR; I'd have it all explained in documentation for the plugin, but I'd include it by default, so they can get up and running with minimal work (since they obviously want it).

[mfrederickson]

Can someone tell me what the "Emergency Alert" and "Emergency RSS" content types are for and how they differ from the "Text" and "RSS" content types? I'd suggest removing them and using the ones that are already provided. It's true that they limit submitting to only the EMS feed, but I'm not so sure that's really important (besides, you may want to test them without actually invoking all the EMS logic).

[mfrederickson]

I've changed the concerto_template_scheduling plugin to prepend to the callback chain, and I've tested with both plugins active and EMS does indeed supercede any scheduled template... in case anyone was wondering if they'd play nice together...

[gbprz]

If it's easier, the emergency content types can be removed since the plugin currently doesn't check the type, only if there is content in the feed. If there is a desire to keep the emergency content types, then the plugin should probably make sure that a response happens with emergency content types only.

[mfrederickson]

My take is that since we've got it using a dedicated feed, that it shouldn't care about the content types-- if there's anything on the feed then activate it. This provides the most flexibility because you can use any content type that we have (that your template handles).

[gbprz]

This sounds good to me, not sure if anyone else has any objections though.