2 APIs and the charter

The Working group charter [0] currently calls for 2 APIs

[[
[a] Social API
A document that defines a specification for a client-side API that lets developers embed and format third party information such as social status updates inside Web applications. One input to this deliverable is the OpenSocial 2.5.1 Activity Streams and Embedded Experiences APIs Member Submission. 

[b] Federation Protocol
A Web protocol to allow the federation of activity-based status updates and other data (such as profile information) between heterogeneous Web-based social systems. Federation should include multiple servers sharing updates within a client-server architecture, and allow decentralized social systems to be built. One possible input to this task is WebMention and another possible input is the Linked Data Platform. Note that the Working Group may not develop the Federation Protocol into a Recommendation and it may become a Working Group Note.
]]

I am having trouble parsing what these APIs are meant to do. 

the social API 
--------------

I read:

"defines a specification for a client-side API that lets developers embed and format third party information such as social status updates inside Web applications." 

This is pretty much unparseable to me. You need to look at the example Open Social 2.5.1 Activity Streams and Embedded Experiences API to get an idea of what is meant. It is just simply a subset of HTTP with information of how you can GET information about a resource, how you can create a resource ( POST ), how you can update an entry ( PUT ), etc...

What does this have to do essentially with Web Applications? And why is this client side? What seems to be meant here is browser only. But why could a "server" not also get the information published in an  activity stream?

In my view being a client and a server is just a role. You are a client if you initiate an HTTP Connection, you are a server if you receive a connection.

What seems to be meant here is an API for reading, updating, creating and deleting a number of information resources containing social data ( and of course content such as pictures ). One determining application of this API is that thick clients  ( eg mobile applications ) should then be written tht can display this information to the human user so that he can then do a number of actions described in the  user stories. But of course a web server could also get this information and create a static page to display it, or use it to run a statistical algorithm on it.

If that is the right interpretation then oddly enough that is exactly what I do using what is termed the "Federation Protocol". I have a JS client in the browser that fetches data from an LDP servers (GET), updates it (PATCH), delete's resources ( DELTE ), etc...  see below.


Federation Protocol
-------------------

I read:

"A Web protocol to allow the federation of activity-based status updates and other data (such as profile information) between heterogeneous Web-based social systems. "

The Linked Data Platform is mentioned here as an example. But I use the Linked Data Platform to do exactly
what is described by the Social API above. I have JS in the browser that reads and writes to the LDP server,
and uses that information to display a dynamic user interface to the user. 

Not only that but I can explore a distributed social web by following links doing that. Wherever 
the client lands ( be it a client written JS in a browser, Java in Android, objective C in the iPhone, 
or just ruby on a server fetching data to build a cache for later use ) I can use the LDP server to
find out how I can update the resource, create one, .... if I am allowed access.

Conclusion
----------

So from my position I cannot find a way of distinguishing between the two APIs. If so
how are we going to decide which user stories fit in one API and which fit in the other? 
How can we start by working on one API and then move to the other API? 

Do we need to alter the Charter to clarify this? Or is it possible to interpret
the charter as asking for two APIs, but for us to come to the conclusion that by
offering one that does both we have satisfied the charter?


Henry Story


[0] http://www.w3.org/2013/socialweb/social-wg-charter
[1] For a bit of an overly technical presentation - this was meant of Scala developers - see the
presentation given in December here. There is a short demonstration towards the end that shows this in 
action:

 https://skillsmatter.com/skillscasts/5960-building-a-secure-distributed-social-web-using-scala-scala-js







Social Web Architect
http://bblfish.net/

Received on Wednesday, 11 February 2015 23:45:19 UTC