November 28th, 2007 | Published in Google OpenSocial
As OpenSocial evolves, we're eager for websites to be able to host OpenSocial apps. To that end, we released an in-memory container sample which includes an early glimpse at the Service Provider Interface (SPI) layer, and you may have heard about the Apache Shindig project proposal, which we're quite excited about. We're still iterating and thinking through some of the open questions, but we wanted to let you know what we're thinking about so we can get your feedback. Here are the highlights (there is a more detailed forum post linked below as well):
Privacy and Security:
API and SPI iterations and refactoring:
OpenSocial is young, and we’re iterating quickly to extend the initial 0.5 spec. One improvement is to cleanly separate the API for app developers from the SPI for container implementors. This split is important to serve both audiences well: the former want a clean, convenient interface for building app; the latter want a clean interface for connecting those apps to their websites. Another improve is to add support for parts of the Google Gadgets API. There is a fairly broad scope to the Google Gadgets API, and, while we're eager to let all gadgets run everywhere, it seems best to start with the bare essentials. For the short term, we've heard that equivalents of IG_Fetch_Content, IG_Adjust_Frame_Height, and IG_Register_On_Load_Handler are crucial components that all containers need to support; if your OpenSocial gadget definitely needs something else, please let us know in the group.
Shindig: open source OpenSocial reference implementation
We're very excited to hear about the Shindig project proposal that is being put together for the Apache incubator, and we'll be contributing both code and engineers to the effort. Shindig hopes to provide a reference implementation for sites that would like to host OpenSocial apps; more on that as it happens.
Policies (gadget directory, discovery, and abuse)
Outside of the more technical conversations, there are many important policy questions. To name a few: How do users discover applications? Is there a central application directory? How can apps let viewers easily “get their own” copy of an app? What happens when an app is reported as malicious?
We’re still working through many of the specifics, but we’re attracted to the idea of an opt-in unified gadget directory as it would let developers have a single point of entry for listing their apps, and let containers offer a wide variety of apps with little effort. In addition, it would potentially allow for unified malware and abuse detection, and some global rankings.
Most importantly, we need your input. If you're considering hosting OpenSocial apps on your website, please review this more detailed forum post and provide your thoughts, concerns, and requirements.
P.S. For this and all future posts, we've turned on blog comments, and we welcome your remarks here. However, for more in-depth comments and discussion, we encourage you to use the OpenSocial group.