- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Wed, 17 Feb 2010 00:19:13 +0000
- 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 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