On 02/26/2011 07:38 PM, John Panzer wrote:
OK, so this case seems to me to be a feed - you subscribe to a topic which
generates 'things' that are separate from the topic itself. It's annoying
that everybody is re-inventing feeds with new syntax, but how many of these
are we really going to see before somebody defines a common minimal base?
The base for JSON could be as simple as having predefined and optional
'guid' and 'updated' fields.
I already tried, a while back:
http://martin.atkins.me.uk/specs/pubsubhubbub-json
My approach was to use the whole JSON object as its own "guid" (that is,
content-addressable objects), allowing higher layers to layer on CRUD
semantics in the content while making the hub part as generic as possible.
I could probably get behind using an id and/or an updated field in
preference to this, but I think it's worthwhile to impose as little as
possible on the payloads so that a hub supporting this can be re-used
for many different applications.
To give a specific example, my JSON pubsubhubbub proposal was intended
to be useful as a transport for JSON Activity Streams, where each
payload is a JSON-serialized activity object or a "tombstone" in a
format TBD. The hub uses the content itself to determine whether this is
a payload that a particular subscriber has seen before, and it's up to
the application layer to recognize the difference between an activity
and a tombstone and handle it appropriately.
