W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Social APIs (was: Rechartering WebApp WG)

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Wed, 17 Feb 2010 00:19:13 +0000
Message-ID: <b3be92a01002161619n64116befq303f22832817c956@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: Scott Wilson <scott.bradley.wilson@gmail.com>, Arthur Barstow <art.barstow@nokia.com>, ext Robin Berjon <robin@berjon.com>, public-webapps <public-webapps@w3.org>
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

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.



> 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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC