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