Some general comments below: On 11/11/07, Tony Stubblebine <[EMAIL PROTECTED]> wrote: > > > I just released the beginnings of a Rails implementation and came up > with a bunch of questions for other people implementing containers. > http://code.google.com/p/rails-open-social/
Great! Please be aware that this may (will) need to change as the APIs move from the current 0.5 to 1.0. Could there be a single javascript container that everyone uses? I > took the Google in-memory container and started overriding it with > AJAX calls to my server and realized that as long as we stick to the > URL convention in the documentation the container code is pretty > reusable. Am I missing something? It's possible. For the full "OpenSocial Stack" we're planning on providing a default connector that implements the necessary AJAX calls, using the standard server APIs. 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. Every time I added a field to my Atom feed I had to add a feed to my > javascript contianer. Is this how it's going to work? I think you mean "had to add a field". Do you mean the people feed? 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. 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. What's the scope of this API? Is it called OpenSocial because the > scope is going to go beyond widgets? Yes, the scope of OpenSocial goes beyond widgets. Obviously in the short term widgets are the most important interface. Does anyone have a clear explanation of what a container needs to do > to display a widget? I'm not talking about the OpenSocial API calls, > just how the widget xml needs to be processed if you don't want to > proxy it to gmodules.com. Is it just a matter of plugging the widget > content section into an iframe? Does it need to be in an iframe? Do > you have to replace some of the require's with javascript code? There are a lot of details involved with doing everything gmodules.comdoes. To be honest I'm still discovering new things. This is one of the key things we're working on to document and provide a reference implementation. In the meantime, the easiest/best route is to simply use or proxy to gmodules.com. Where are all the partners? I don't see many posts from them on this > list but I've heard through back channels that they're plenty > confused. This is the only list for container developers right? Right? Yes, this is the list. There may be other conversations over on the opensocial-api list as well (primarily focused on app developers though). Thanks for the feedback! John --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
