The Activity Streams project, which is hopefully nearing completion of its first version, is build apon the Atom syndication format. This design decision was made in order to afford relatively easy adoption by those who already publish feeds, in much the same way as Microformats like XFN are relatively easy to adopt for those who are already publishing HTML. This has had mixed success, since most of the implementations so far have been fresh implementations or feed-like APIs that make use of the format.
One thing that has been raised relatively often during the development of this first iteration of Activity Streams is the possibility of a JSON serialization. JSON is, after all, often easier to process due to the fact that its data model matches better the data structures offered in most popular programming languages. This discussion causes some contention between members of the Activity Streams community, perhaps due to the existing investment in Atom as the base serialization format or concerns about the fact that JSON has not yet proven itself as a good format for extensible data models.
At this point I'd like to go on record as supporting an effort to define a JSON serialization. A while ago I published a very early draft of what JSON Activity Streams might look like, and that spurred some discussion about the merits of this vs the existing AtomActivity specification of which I'm a co-author.
The important thing to realise is that Atom Activity Streams and JSON Activity Streams both serve distinct needs. A goal of Atom Activity Streams is to allow ad-hoc integration of arbitrary implementers, by building on the infrastructure that Atom and RSS have already established. I can add any blog I like — along with just about any other non-blog content — to my feed reader of choice and it will, with some caveats, work. Activity Streams aims to add some additional markup to bring that kind of interoperability to the world of activity publishing, as RSS and Atom did for content publishing, while remaining compatible with existing implementations and infrastructure where it makes sense.
As a pertinent example, making use of Atom allowed Activity Streams to benefit automatically from PubSubHubbub, which allows activity notifications to be transmitted in near-realtime between the producer and any interested consumers without any additional specification work. Recently Google launched Buzz which demonstrates how these two technologies can be combined while still allowing for the use of traditional content feed consumers.
JSON Activity Streams, on the other hand, are likely to serve more as an integration format between two specific implementers. As an analogy, consider that OpenID supports ad-hoc association between any pair of compliant consumers and providers, while OAuth is designed for specific integrations between two strongly-coupled services. The benefit of defining JSON Activity Streams is not to allow ad-hoc federation but rather to allow code re-use and knowledge re-use when activity information appears within an API, much as I can re-use the same OAuth library when I make specific integrations with the APIs of both Twitter and TypePad but I still need, to a certain extent, to do some custom work for each.
While it is definitely preferable to allow ad-hoc integrations rather than require tightly-coupled integrations, there is a trade-off between the complexity that ad-hoc integration requires in order to support decentralized extensibility and interop with a variety of implementations vs. the relative simplicity of integrating with one external service and doing that well. The friction of a tightly-coupled integration can still be reduced by a shared understanding of protocols that promotes the ability to share as much code as possible between different integrations and make use of battle-tested third-party libraries to handle the hairy details.
So what do I see as the future of JSON Activity Streams? I expect that its use will largely be limited to being used as a common vocabulary for otherwise-proprietary APIs, probably requiring an existing business relationship authenticated by either OAuth or one of its potential successors. Meanwhile, Atom Activity Streams remains a useful way to add Activity Streams semantics to an existing, publically-available Atom feed to allow progressive enhancement that achieves more useful presentation in activity-aware clients while remaining usable for already-deployed software.
With all that said, the immediate focus I share with the other Activity Streams authors and the community is publishing a solid spec for the Atom serialization and its associated serialization that covers a large number of use-cases observed in the wild today. I feel it's more important to focus on one generally-useful approach first rather than expanding the scope so far that we'll never finish.
My JSON Activity Streams draft will remain available to document my currently-favored approach: to more directly model the properties of activity objects and to simplify the processing model compared to that required for Atom Activity Streams. I have a rough implementation of this format on my personal site, but it's by no means comprehensive. It is my hope to eventually use the abstract data structures defined for JSON as a canonical representation of the Activity Streams data model, in terms of which the other serializations will be defined. For now, the activity schema is defined in terms of the Atom serialization and I think this is a good place to start for the first iteration.
Comments