On 02/18/2010 10:38 PM, David Recordon wrote:
What would JSON provide other than syntactic preference?
The Activity Streams group is also starting to work on a JSON version
(based on implementor feedback), but losing push would be a poor tradeoff.
Another use case would be letting people subscribe to changes in a
user's Portable Contacts file. I update my photo and that's pushed out
to sites who have subscribed to it.
Best Buy also has a products API which I could subscribe to inventory
changes of iPod stock near me:
It seems to me like JSON is at the wrong layer for this.
JSON exists at the same layer as XML in the technology stack, while
PubSubHubbub targets Atom, an application of XML.
I think it makes more sense to think about what it might look like to
use PubSubHubbub with particular JSON-based formats rather than generic
JSON. For example, one could specify how to use Hubbub for JSON Activity
Streams, assuming JSON Activity Streams was actually ready for use.
Activity Streams JSON is an application of JSON that has a defined
top-level atomic object (an "activity") much as Atom has "entry" as its
top-level object, so it ought to be much more straightforward to define
PubSubHubbub for Activity Streams JSON than for generic JSON or any
other format which does not necessarily have a list of something as its
top-level type.
(As a side note, at its core the draft JSON Activity Streams format is
just a JSON object with an "entries" property whose value is an array of
objects, so you could also imagine defining a PubSubHubbub binding for
that sort of data structure, where the top-level objects are the
contents of that array, but it still feels like this is too low-level to
have much practical utility.)
