Where's my 'Write once, run anywhere'?

[Chris]

So we're already seeing wrappers being made for OpenSocial to handle
the different implementations on Orkut, Hi5 and Ning? Wasn't that
Google's job?

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>

[JevS]

To Chris,
I agree, that Google should take more care on OS standards. For
example, not clear if and how user preferences will be implemented
(Ning and hi5 not having any support for this) or what is recommended
maximal width for OS gadgets. At the same time, Google could not be
responsible for implementation differences. Each container is having
specific architecture. For example, there are no usual user profiles
in Ning (except some basic info - name, photo,etc) - real profiles are
created for networks (possible this is reason for new argument
'origin' - network ID). Possible we have to say - write once for one
container and then it will be easy to rewrite it for another.
PS. Your example working fine for me in Orkut after one minor change :

document.getElementById('message').innerHTML = 'Requesting
friends...';

Cheers.

[Reinoud Elhorst]

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/240a3a5c247c1b5f/09268a3856a55f12

[Paul Lindner]

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

> You received this message because you are subscribed to the Google Groups "OpenSocial API Definition" group.
> To post to this group, send email to opensoc...@googlegroups.com
> To unsubscribe from this group, send email to opensocial-ap...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/opensocial-api?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

--
Paul Lindner
hi5 Architect
plin...@hi5.com

[bainfu]

To call even the spec beta is extremely generous. I almost pulled my
hair out trying to figure out why I couldn't pull my friends list in
Safari when it worked without problems on firefox. I don't know if I
was relieved or disappointed when I finaly found the open issues list.

[Chris]

Hi Jev,

>>Possible we have to say - write once for one
container and then it will be easy to rewrite it for another.

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

[Chris]

Well, maybe this was a case of the PR machine being too far out front
of the technical reality. But when I see a launch video and a list of
companies using OpenSocial, and TechCrunch reports on it so
positively, I figure it's ready for some action, not still under
development.

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

This scares me. Browser wars, anyone?

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.

[Arne Roomann-Kurrik (Google)]

Hi Chris,

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

[shas...@gmail.com]

hi,
Can u send me source code for pulling friend list in my application in
Orkut. I tried all possible codes but it did not work.

Thanks
Shashi Kant

[Arne Roomann-Kurrik (Google)]

Hi Shashi,

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/firstgadget-0.6.html.
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: