Re: Rechartering WebApp WG

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