Re: Social APIs (was: Rechartering WebApp WG)

On Sat, Feb 13, 2010 at 8:52 PM, Doug Schepers <schepers@w3.org> 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.
>
> 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.
>
> 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.
>

Yes, we over in the Social Web XG would be happy to provide some space
where efforts like this one can be done, in particular a "Social API
requirements" telecon and e-mail discussion with WebApps would be
great. Looking at the list made earlier:

"* access to contacts on a specific device: Contacts API (DAP WG) [4]"

This is obvious an important point, but we need to make sure that
Contacts API is compatible with PortableContacts/vCard, and maybe even
look at FOAF.

" * 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 think this could be covered by some new
API.

Agreed, and we could also make sure that those in RDF have a
declarative metadata approach that is compatible with some new API,
but that users of such a API would not have to know about or use, i.e.
compatible but orthogonal.

 Personally, I believe that if the relevant stake-holders can be
brought on board, this would be a very worthy area for future
standardization and will do everything I can to help. Looking at our
schedule, we were hoping to have a call on this topic (i.e. W3C
Widgets and OpenSocial), March 10th (5 PM GMT) still works [1].

For a general update on our work, take a look at our minutes [2] and
wiki [3]. We'll have a draft final report out by end of March, but
expect the XG to be extended by 3-6 months as we are still in the
middle of a number of conversations.

  -harry

[1]http://www.w3.org/2005/Incubator/socialweb/wiki/Schedule
[2]http://www.w3.org/2005/Incubator/socialweb/
[3]http://www.w3.org/2005/Incubator/socialweb/wiki/


>
> 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.)
>>>
>>>
>>
>
>

Received on Wednesday, 17 February 2010 00:19:42 UTC