Re: Rechartering WebApp WG

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 Friday, 12 February 2010 23:50:22 UTC