On Sun, Nov 11, 2007 at 10:15:36AM -0800, John Panzer wrote: > Some general comments below: > > On 11/11/07, Tony Stubblebine <[EMAIL PROTECTED]> wrote: > [...]
> > Why is OpensocialReference.js obfuscated? It's one of the files that > > Google distributed in their in-memory container release. I'm pretty > > sure it implements the parent container class, but I couldn't get that > > class to do anything. > > It implements default implementations to reduce the necessary amount of > boilerplate in each individual container. Not sure why it's obfuscated > though. I believe that the legal team has yet to sign off on releasing this code to people that have not signed NDAs. >> Have people looked at the Hi5 javascript container? One thing they > > realized is that despite the Google docs about a server-side API, the > > real API to the widgets is the Javascript container. So they took a > > completely different approach on the server side (FOAF and JSON). I > > like this but wonder if it's going to cause trouble later. Does anyone > > have an opinion? > > A couple of points -- in the short term, it's absolutely true that the real > API for gadgets is implemented by the client side JS API in the containing > page. In the long term, it's important to have interoperable server-side as > well as client-side APIs. So when we're able to use server to server calls > as well, we won't have to deal with an explosion of server APIs. > > This doesn't mean that containers can't or shouldn't expose data in multiple > ways of course, just that there should be at least one standard OpenSocial > way. hi5 developed our container using already existing API calls. This allowed us to quickly support the Javascript API. We are actively working to support the server-side protocol as well. > > One other nice thing about the Hi5 code is that it's more AJAX ready. > > I realized as I was working with the Google code that since you can do > > multiple API calls in the same request, leading to multiple AJAX calls > > to your server, you need to build a javascript queue to handle the > > responses. The Hi5 code already does that. Probably does a lot more, > > but that's as far as I've gotten. > > Batching of requests is an important topic -- it's also useful for server to > server interactions. It would be great to discuss what's needed here more > generally. Agreed. Right now an instantiation of an app on hi5 requires downloading a few javascript files and two requests for FOAF files for OWNER/VIEWER to get profile/friend data. In the future there will also be requests for app data and more. As far as our callback code goes I'd be happy seeing it integrated into the in-memory container as long as it does not impact readability. [....] -- Paul Lindner hi5 Architect [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenSocial Container Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-container?hl=en -~----------~----~----~----~------~----~------~--~---
