Decide Hive implementation of new "reasons"

[agates]

We need to determine the best way to implement the reason codes going forward. Currently with the 0.3 podping hive schema they are in the custom_json itself.

However, @brianoflondon mentioned in #9 that it may be better to implement new reasons as different custom_json operation IDs.

We need to determine the best course of action before we can fully implement reasons end-to-end.

Will get together and discuss at some point (maybe on the dev call)

[agates]

We will be putting the reason codes as well as medium slugs directly into the operation_id, moving them out of the payload. We decided this will be beneficial to efficiency as podping usage grows.

The reason for this is the operation_id is critical to how Hive applications function and the APIs are written. It is the best way to filter out data directly from a Hive API server. Therefore, while it's a little more work up front for watchers, this decision will allow clients to be a little bit more efficient in bandwidth for the events they receive by allowing them to ignore mediums and/or reasons they are not interested in.

I'm thinking the format will look something like this:
{podping}_{medium}_{reason}

Where podping will expand to the following:

• podping
• podping-livetest -- basically what we use during development

Where medium will be one of the slugs outlined in the medium specification of the "podcast" RSS namespace extension (as of this time of writing):

• podcast
• music
• video
• film
• audiobook
• newsletter
• blog

Where reason will be one of the following, open to additions with careful consideration and definition of purpose:

• update -- A general indication that an RSS feed has been updated
• live -- An indication that an RSS feed has been updated and a contained <podcast:liveItem> tag's status attribute has been changed to live.

A few other reasons have been considered, such as indication of feed host changes, but we have decided to forego them for the time being as they require consideration to avoid abuse, perhaps to be mitigated by extra requirements related to the yet-to-be finalized <podcast:podping> specification.

Given the above information, an example operation_id of a podcast publishing a new episode will be:
podping_podcast_feed-update

And publishing a music album will look like:
podping_music_feed-update

A podcast starting a live stream would look like:
podping_podcast_live

A video stream going live:
podping_video_live

If you have any questions or changes, this is by no means finalized and we will only be publishing under podping-livetest until development is finished.

[agates]

Going to decide to limit medium and reason strings to single words for simplicity and the recent discovery of the hive operation ids being limited to 32 characters

i.e. feed-update -> update

[daveajones]

Looks cleaner.