Custom JSON element 'reason' isn't fully implemented

[seakintruth]

There's currently no way for a caller to request that the reason element be anything other than 'feed update'.

To implement this:

• A third optional argument needs to be added to the function send_notification that defaults to 0.
• The function url_in, needs a similar second optional argument
• And the part I don't know how to implement, the handle function of the MyTCPHandler class must be able to parse the expected reason from the sender's message.

[seakintruth]

I see that the currently planned reasons are: ['feed_update','new_feed','host_change'] would it make sense to add a 'feed_deleted' reason to signify when a user takes the action of deleting a podcast feed (it appears most hosting companies allow users to flag a podcast as deleted).

[seakintruth]

Maybe different API endpoints for each action?

[agates]

The most recent code is in the develop branch... this is on the roadmap (we've been distracted significantly)

[agates]

Going to be looking at this for a 1.1 release -- once we get 1.0 in more hands and tested.

[brianoflondon]

I'm really leaning heavily toward moving the reason code out of the custom_json and into the wrapper so that we tag with :

podping_<reason>

This is fundamentally important for Hive. It is far better to have as many custom_json types as we want all prefixed with podping_ as this is indexed by all the major Hive systems whereas the contents of custom_json payloads is not.

[agates]

It's a breaking change right? Can't think of a way to make it a smooth migration for clients unless we double post two different operation types.

[brianoflondon]

It's technically a breaking change but as we only have one reason code in production I don't think anybody is looking at the reason code in the custom_json.

There's no reason not to duplicate it within and without though besides wasting a few bytes so we can do that.

[agates]

They aren't looking at the reason code but they are looking at the operation_id, that's how we filter messages.

What else does this gain us?

[brianoflondon]

I think we leave podping as the default operation_id for feed_update as it is now, but most other reason codes we come up with should be podping-something. This makes it possible to filter blocks more easily if one only wants live updates.

I don't know 100% how this will operate with HAF but I'm pretty sure it's going to be important.

[agates]

Tracking the request/response here https://github.com/Podcastindex-org/podping-hivewriter/issues/16

[agates]

@seakintruth hopefully #18 answers your concerns. We're going to be removing the reason out of the custom_json payload into the operation_id.

[agates]

Implemented in 1.1, feel free to test your statistics stuff against the livetest prefix pplt_. I think @brianoflondon is also cross posting 3speak stuff already.

Github release coming later tonight with more details