[OS3 Proposal] Core Services Revamp

7 views
Skip to first unread message

James Snell

unread,
Feb 3, 2012, 6:54:48 PM2/3/12
to OpenSocial
As an addendum to the Core API rework proposal in my previous note,
and building off the themes established therein, I am also working on
proposals for a revamped collection of Common API services. Currently,
the OpenSocial specification defines the Cache Service and a number of
RPC-protocol mechanisms for discovery, Because the RPC protocol is
dropped, those can be dropped as well and the Cache service can be
simplified even further.

The attached document is *an initial first draft* describing three
core services, and a place holder for a fifth. Additional work needs
to be done to flesh this out fully, obviously, but I wanted to at
least get these on the table for discussion.

1. Revamped Application Data Service... this pulls the AppData service
from the Social API spec and models it as a Core Service with a
greatly simplified and more flexible interface.

2. Revamped Cache Service... this is a fairly minor modification and
simplification of the existing Cache service that removes the
requirement to encode the invalidated cache keys as JSON or XML.
Rather, each are listed directly in plain text, separated by
LF/CR/CRLF. Eliminates the extra, unnecessary, and ultimately
pointless JSON/XML parsing.

3. Introduces a new Persistent Query Service. This makes it possible
for a client to create persistent searches that can be independently
managed. Still quite a bit to define here, but the idea is to make it
easier for applications to perform a variety of data retrieval
operations that currently aren't easily supported in the API. For
instance, pulling up details for an adhoc but persistent grouping of
profiles, etc.

4. Will eventually proposal a new Proxy Service... which will provide
an interface for proxying requests to remote services with
authentication, caching, and conditional request mechanisms managed by
the server.

This is just a draft, posted for discussion purposes....

Expect additional information for each of the proposed new services in
the not too distant future.

core.services.txt

Mark W.

unread,
Feb 6, 2012, 7:07:59 PM2/6/12
to opensocial-an...@googlegroups.com
James,

A couple of thoughts, with the caveat that I have not fully studied these proposals in their entirety. That said...

First, for consistency, would you also post this to the wiki as a new proposal? (http://docs.opensocial.org/display/OSD/Spec+Changes+-+v3.0)

Also, I think we need to recognize that we've got a large install base of containers and apps. What's the migration plan.

I noticed patch as a supported verb. In practice, it's often very difficult to get IT shops to support patch. This could limit the adoption of this.


-Mark W.

p.s. Why is there all the IETF language on this?

James Snell

unread,
Feb 6, 2012, 7:16:02 PM2/6/12
to opensocial-an...@googlegroups.com

I am currently unable to log into the wiki. As soon as I am able I will get in and add everything. As for the ietf boilerplate, I use xml2rfc for all my standards draft stuff by default so it just Carries through to here... Feel free to ignore those bits.

Migration plan is forthcoming. I will post details for that in the time before the summit at the end of the month.

Use of PATCH can be augmented with the use of the already supported method override header. Support is ramping up for additional extension methods and the fact that there are other deployed production apps with support for patch (e.g. Some of the google apis) will help the picture improve further.

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/qPIRMqwW0WgJ.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

Matthew Marum

unread,
Feb 7, 2012, 11:27:26 AM2/7/12
to opensocial-an...@googlegroups.com
There are a couple of main points I'm interested in as far as expanding the Social APIs.  I do think James proposal accomplishes them, but I'd like to document what they are so we can agree on goals and not lose sight of them as we start hashing out the details.

1) API Versioning - without this evolving the APIs over time becomes cumbersome

2) Discoverability of resources - service discovery, enhancing query support, gadget catalogs, etc.  For example, I cannot access a Person resource until I know the User-Id.  What happens if I only know a Person's name and not their User Id?  How can I figure out their URI using the OpenSocial REST APIs today?  As far as I can tell, you can't.

3) Enhancing the consumability of the Activity Stream - the Activity Stream is the main integration point that applications are starting to use.  Applications want to host Activity Streams or post embedded experiences to Activity Streams.  The way the spec is written it seems like Activity Streams are centered around people as the primary Actors but I'm not convinced that always makes sense for system generated Activities.  Instead of layering on Groups, AppIds, ActivityIds, etc, could we just center an activity stream on any URI or resource in the social graph?  This would make Activity Streams easier to consume.

4) Federated social resources - I'd like OpenSocial REST APIs to be able to support having friends span across social containers, for example.  Or have my Activity Stream and my Profile data hosted on different social containers.  I think Global-Ids kind of support this sort of thing today but I'm not really convinced that this would work in practice.

Please feel free to comment or add more  If these are in the right ballpark, I can update the 3.0 REST API wiki.

Matt
Reply all
Reply to author
Forward
0 new messages