And whose wrapper is going to be consistently updated and tested?
Chris Chabot has gotten some press with his, but Jevgenijs Sallinens
is extending it already. In 6 months, we'll probably have 3 more to
choose from.

I'm tired of this meta-meta-meta crap. Can't Google just cross all the
T's and save us all this added complexity?

Chris

PS: This simple example works for me on Ning, but not Orkut or
iGoogle:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
 <ModulePrefs title="List Friends Example">
   <Require feature="opensocial-0.5"/>
 </ModulePrefs>
 <Content type="html">

 <![CDATA[

 <script type="text/javascript">

  function getData() {
    document.getElementById('message').innerHTML = 'Requesting
friends...';
    var req = opensocial.newDataRequest();
    req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
    req.add(req.newFetchPeopleRequest ('VIEWER_FRIENDS'),
'viewerFriends');
    req.send(onLoadFriends);
  };

 /**
  * Parses the response to the friend information request and
generates
  * html to list the friends along with their display name and
picture.
  *
  * @param {Object} dataResponse Friend information that was
requested.
  */

  function onLoadFriends(dataResponse) {
    var viewer = dataResponse.get('viewer').getData();
    var html = 'Friends of ' + viewer.getDisplayName();
    html += ':<br><ul>';
    var viewerFriends = dataResponse.get('viewerFriends').getData();
    viewerFriends.each(function(person) {
      html += '<li>' + person.getDisplayName() + '</li>';
    });
    html += '</ul>';
    document.getElementById('message').innerHTML = html;
  };

  _IG_RegisterOnloadHandler(getData);

  </script>

  <div id="message"> </div>

  ]]>
  </Content>
</Module>

I think it's not fair to judge a product on beta implementations of a beta
specification. When the specification reaches 1.0 (or possibly before), and
implementations become more stable, we should see an environment where
everything is accessable though the same opensocial namespace. Obviously
there will be differences between containers, but there will be a common
base that is supported on all containers, some parts that are supported by
most containers, and some extensions that are supported by only a single /
couple of containers. Indeed, there shouldn't be a need then for 3rd party
libraries to bring consistency between containers (it is quite likely though
that some 3rd party libraries will be useful for general OS gadget
development).

Also see the discussion here
http://groups.google.com/group/opensocial-api/browse_thread/thread/24...

On 11/30/07, JevS <jevgenijs1...@gmail.com> wrote:

hi5 will support the full specification.  Others are committed to the
same.   This compatibility library should not be necessary then.

Sorry for not having much time to post on the list, we're doing lots
of stuff behind the scenes to prepare our site for widespread
OpenSocial use...

application_pgp-signature_part < 1K Download

Agreed. Of course, that's not the value proposition that's been
offered. :)

I don't see a difference in the line of code you provided than in my
original. However, I did discover the code wasn't working for me
because I'm using Safari. In Firefox, it did run. Thanks!

Chris

On Nov 29, 11:46 pm, JevS <jevgenijs1...@gmail.com> wrote:

Without strong top-down control, containers will go off and extend
functionality in new ways for their users, just as IE did. And web
devs know how wonderfully that worked out for us. How many times do we
ask ourselves why code works in all browsers except IE? And how many
IE-specific fixes are there out there?

It's just surprising that a company would propose an inclusive, 'make
life easier for devs' product, and then not maintain the quality
control necessary to realize that goal.

Plus, it's in the container's long term interests to abide to a common
spec. A common spec is easier to develop to, which means more devs
will try it, which means containers will get more apps.

    This early in the API definition, we're likely to see
implementation bugs that can break functionality for OpenSocial
applications.  The IE and Safari incompatibility in Orkut's sandbox
has been documented in the "OpenSocial Issues" page (http://
groups.google.com/group/opensocial/web/opensocial-issues) and seems to
have been what was causing your example to fail on Orkut.  Naturally,
we're highly interested in receiving bug reports from developers, so
please contribute any problems you're seeing to that page.

    This isn't to say that your hesitation regarding container
implementation differences isn't valid, and that we shouldn't be
worried about delivering a cross-container development experience that
is frustrating to programmers.  I believe that the Shindig project
(http://wiki.apache.org/incubator/ShindigProposal) will go a long way
toward ironing out API implementation inconsistencies, as well as
providing a container-agnostic implementation of the OpenSocial API
that application developers can test against.  Having it be an Apache
project emphasizes the route we want to take with OpenSocial - not
owning the spec, but rather encouraging contribution and participation
from the larger developer community.

~Arne

On Dec 3, 5:12 pm, Chris <ch...@wildsky.com> wrote:

Thanks
Shashi Kant

On Nov 30 2007, 9:59 pm, bainfu <bain.kenn...@gmail.com> wrote:

   Please try to run the code in the "How To Build Your First Social
Gadget" article available here:
http://code.google.com/apis/opensocial/articles/firstgadget/firstgadg....
This example shows fetching a list of the viewer's friends.

~Arne

On Jan 19, 12:33 am, "shashi...@gmail.com" <shashi...@gmail.com>
wrote: