Re: Social APIs (was: Rechartering WebApp WG)

On 13 Feb 2010, at 20:52, Doug Schepers wrote:

> Hi, Scott-
>
> This is certainly a valid aspect of Widgets... as a platform for a  
> specific kind of Web application: a collaboration/discussion/sharing  
> app.
>
> But it seems to me that this is conflating two orthogonal things: an  
> application host environment, and a collaboration platform.  Widgets  
> can host the full range of Web apps; and a collaboration platform  
> shouldn't be confined to Widgets.
>
> The context for a Widget, in my opinion, shouldn't inherently  
> contain the users of that Widget; that is functionality that should  
> be specific to collaboration apps.
>
> As an analogy, think of the Geolocation API.  A recipe widget which  
> finds recipes based on a list of available ingredients has no use  
> for that API, but a shopping widget might; traditional web sites  
> built to do those things would have the same needs.  So, the  
> Geolocation API is much better off as a standalone API that is  
> available when needed, and not imposed when not needed, as general  
> functionality, not just for Widgets.

Agreed. A Widget is only one possible consumer of such an API, so it  
make sense to define the API separately (with Widgets as one type of  
use case).

> It also seems that it would require more than just an API... it  
> needs an infrastructure from which to draw the relationship data,  
> and security considerations.  Like the Geolocation API encapsulates  
> underlying device/service functionality (GPS, cell/wifi  
> triangulation, logged IP locations, etc.), and the Widget  
> Interface's Storage API uses functionality defined elsewhere  
> (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web  
> service), a Social API would have to rely upon some source of data,  
> which is not inherent in the device or a single established web  
> service, so that would need to be defined.

Indeed, both collaborative and social apps require the container to  
have a means of access to a data source, and are also responsible for  
applying appropriate access and privacy policies; a parallel here  
would be DAP (and OMTP BONDI).

> I don't think the WebApps WG is the right place to work on a Social  
> API; I don't think it would get the specific interest such an API  
> would require to do it right, with the current participants of this  
> group (though others in the group should correct me if I'm wrong).   
> Also, the WebApps WG has an urgent need to renew its charter to  
> bring in deliverables we've already agreed are in scope, so I would  
> be extremely reluctant to bring in a deliverable at this stage that  
> has as broad a scope as a Social API.
>
> That's not to say a Social API is not useful or desirable.  I'd love  
> to see this done at W3C, and I think it's important to make sure it  
> works well in both web sites and widgets.  So, my counterproposal is  
> to suggest that you work with Harry Halpin to propose a new Social  
> API WG (maybe under Interaction Domain, but more fittingly under the  
> Technology and Society Domain), and bring in the Google Wave and  
> Open Social folks (since Google is already a W3C member), and find  
> other stakeholders (Facebook?) who might also be interested, to help  
> standardize what they have all already done.  Harry and I have  
> talked a bit before about next steps for the Social Web, and this  
> strikes me as a logical and pragmatic next step.  I will be happy to  
> do what I can to help set this up, and to ensure good communication  
> between our groups, and to make sure that it works well with Widgets.

I think this is a very good proposal; I'm happy to drop the proposal  
for doing this in Webapps and work instead with the Social Web group  
as you suggest.

>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
>
> Scott Wilson wrote (on 2/13/10 5:21 AM):
>> Hi Doug,
>>
>> I'm not adamant that these requirements are met specifically just for
>> Widgets, just that these are where the current use-cases come from.  
>> They
>> certainly ought to be supported through more general technologies  
>> where
>> possible.
>>
>> There is also the issue of abstraction; should a widget author be
>> looking at low-level APIs to deliver functionality, or call a common
>> high-level API which is then implemented in a
>> device/architecture-specific way? E.g. if a widget author script  
>> wants
>> to get the list of current participants, should it need to be  
>> rewritten
>> for every platform it might be deployed in (e.g. XHR in some, Web
>> Sockets in another, native code another...) or can it call
>> "widget.getParticipants()" and let the UA handle the implementation?
>>
>> Just as, for example, the Widget Interface defines "preferences"  
>> using
>> the Storage API: the actual choice of implementation of this
>> (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web  
>> service) is
>> up to the UA.
>>
>> So what I'm talking about here, just to be clear, are the high  
>> level API
>> abstractions available to a running widget (and potentially other  
>> types
>> of web application) and not any underlying protocols used to  
>> implement
>> them.
>>
>> The specific high-level APIs I'm interested in are:
>>
>> 1. Participants [1]: getParticipants, getViewer, getOwner,
>> setParticipantCallback
>> 2. State [1]: getState, state.submitDelta, state.submitValue,
>> setStateCallback
>> 3. Friends/People [2]: getViewerFriends, getOwnerFriends
>>
>> (Note these are subsets of the functionality of the referenced
>> specifications; other functionality they specify is already covered  
>> by
>> other W3C work such as Widgets:TWI [3] and Widgets:VMMF[4])
>>
>> In some cases these APIs could map onto DAP (e.g. getViewer would  
>> map to
>> a call on the Contacts API) but in other cases would rely on other  
>> kinds
>> of implementations (OpenSocial itself, XHR, Websockets, Widget  
>> Feature
>> extensions etc). The principle interoperability being addressed  
>> would be
>> a consistent runtime model for a widget author irrespective of
>> deployment environment.
>>
>> Widgets P&C already has a Feature extension mechanism for handling
>> availability of additional APIs that would be well suited to  
>> negotiating
>> availability of these types of APIs [5]. Apache Wookie already
>> implements Widgets P&C with a subset of the Google Wave Gadget API in
>> this fashion [6].
>>
>> S
>>
>> [1] http://code.google.com/apis/wave/extensions/gadgets/ 
>> reference.html
>> [2]
>> http://wiki.opensocial.org/index.php?title=OSAPI_Specification#osapi.people
>> [3] http://www.w3.org/TR/widgets-apis/
>> [4] http://www.w3.org/TR/2009/WD-widgets-vmmf-20091006/
>> [5] http://www.w3.org/TR/widgets/#the-feature-element
>> [6] http://incubator.apache.org/wookie/
>>
>> On 12 Feb 2010, at 23:50, Doug Schepers wrote:
>>
>>> Hi, Scott-
>>>
>>> I'm still confused as to what you're asking for as a chartered
>>> deliverable for Widgets.
>>>
>>> Like others, I am extremely reluctant to define any special
>>> functionality for Widgets, when it could be useful for Web
>>> applications at large. Let me try to break down some of what you are
>>> asking for in terms of specs we are already doing:
>>>
>>> * communication between different widgets on the same computer: Web
>>> Messaging [1]
>>> * communication between widgets on different computers: Web Sockets
>>> API [2], XHR [3] (through a gateway server)
>>> * access to contacts on a specific device: Contacts API (DAP WG) [4]
>>> * access to relationships between contacts, etc.: no current work,  
>>> but
>>> possible as an online service (XHR), or locally through markup like
>>> RDFa or microdata
>>>
>>>
>>> I don't know what social APIs OpenSocial or Google Wave Gadget API
>>> expose, but anything above and beyond the deliverables listed above
>>> should probably be developed by another group (maybe in  
>>> collaboration
>>> with the RDFa WG, since it probably has to do with ontologies?), and
>>> simply reused within Widgets or Web apps.
>>>
>>> But maybe I missed your point... can you give me a concise outline  
>>> of
>>> what the specific use cases and requirements you have for this  
>>> social
>>> API are?
>>>
>>> [1] http://dev.w3.org/html5/postmsg/
>>> [2] http://dev.w3.org/html5/websockets/
>>> [3] http://dev.w3.org/2006/webapi/XMLHttpRequest/
>>> [4] http://dev.w3.org/2009/dap/contacts/
>>>
>>> Regards-
>>> -Doug Schepers
>>> W3C Team Contact, SVG and WebApps WGs
>>>
>>>
>>> Scott Wilson wrote (on 2/12/10 5:39 PM):
>>>>
>>>> Specifically I'm thinking of access to friends/friends-of lists  
>>>> from
>>>> author scripts in a Widget runtime. This is something of interest  
>>>> to
>>>> widget developers, as it enables widgets to operate as social
>>>> applications.
>>>>
>>>> OpenSocial is an obvious source of inspiration here - however the  
>>>> actual
>>>> social APIs are only a small part of OpenSocial (which also  
>>>> covers all
>>>> aspects of app packaging. processing. discovery and persistence)  
>>>> and are
>>>> not easily reused in other kinds of devices and architectures.
>>>>
>>>> The interop problem arises as currently authors of apps/widgets are
>>>> basically faced with two completely different "stacks" of  
>>>> specifications
>>>> based on the presence or absence of a few very small features -  
>>>> and the
>>>> "friends" API represents the main feature gap between the W3C  
>>>> widgets
>>>> family of specifications and OpenSocial.
>>>>
>>>> Looking at recent developments, e.g. Vodafone's recent work on
>>>> integrating phone contacts and social network contacts, suggests  
>>>> that it
>>>> will not only be web widgets that would be able to access this  
>>>> type of
>>>> API, but also mobile and desktop widgets.
>>>>
>>>> I would propose looking at this area with the W3C Social Web XG and
>>>> identifying a set of spec requirements either for webapps or DAP  
>>>> (it
>>>> could go either way - social APIs may fit better in DAP as they  
>>>> have
>>>> analogues with the contacts API work there, however Widgets are the
>>>> obvious vehicle for making use of such APIs. In any case some
>>>> co-ordination would be useful).
>>>>
>>>> Currently in Apache Wookie we implement the Google Wave Gadget  
>>>> API as a
>>>> means of supporting inter-widget communication in collaboration
>>>> scenarios (e.g. multi-user environments); however the fact that  
>>>> this API
>>>> is completely different in almost every respect from the Google  
>>>> API to
>>>> get at friends (as opposed to participants) indicates there is a
>>>> significant interop gap where W3C could make a difference.
>>>>
>>>> (One way of looking at this is that requesta for "contacts",
>>>> "participants" and "friends" are just differently contextualized  
>>>> queries
>>>> on a core "people API" and should behave consistently.)
>>>
>>>
>>
>