Firstly, opensocial gadgets at this moment are only content type html, as far as I understand it. This way, this API is only defined at the javascript level, and everything else is left to implementation by individual containers. I believe that is the right way to go for the 1.0 version of OpenSocial: it allows for quick deployment of containers on sites that are totally different internally. I can definitely imagine that a future version of OpenSocial will allow for the url-type, and perhaps define the gadget-container interaction on a different level.
I believe you are right about the basic concept of what information is needed though: - A link to the JS container.js file (since I don't want to keep my own list of which network has its container.js file on which url). Perhaps the network-name could be useful for black/whitelisting containers from a gadget-developer point of view - Credentials. This is a little trickier though, since some networks might first want to pop up a message to the user "Do you want to login to Gadget-abc123?". I believe oAuth has little to do with this (that is more for the dataAPI), and I wouldn't see the advantage of defining what format these credentials these are in: Just send the credentials with every call to the container and it'll know what to do - view There are some talks of dropping the iframe-security and replacing it by Caja (in the futute, on some containers). I wouldn't be too sure on how this would interact with the content-type=url either. On 11/30/07, Chris Waterson <[EMAIL PROTECTED]> wrote: > > > I'm trying to get my head around all this stuff. > > I want to implement an OpenSocial container. > > At least one of the Gadgets that I want to support is going to have to > be rendered from a remote site, and would therefore be a "url" > content-type Gadget. > > I took a look at Hi5's friend list sample code, and it seems like > they're packing *all* the information required to initialize the > gadget into the request URL. This seems wrong, if only because > there's no way for the gadget to access the mutator APIs, like, say, > posting activities. (Well, okay, *they* can, because they're actually > hosting the gadget from hi5.com.) > > But, I'm also guessing that this was a quick and dirty hack to > demonstrate progress, and not really how a "real" gadget would work? > > What I would have thought should happen for the gadget to communicate > with the container would have been that some initialization goop is > passed via the request URL that tells the gadget: > > * Where to find the container, i.e., "you're instantiated in > mysocialnetwork.com". The gadget will need to know this in order > to invoke my container's OpenSocial Web APIs. (Since the > container and the gadget are in different domains, they can't > communicate via the JavaScript API.) > > * The credentials of the person who is invoking the gadget. These > credentials will be used to communicate with the container. I'm > guessing this is where OAuth comes in, but understand very little > of that right now. > > * Which "view" of the gadget we'd like to see, so the gadget knows > whether to render "canvas" versus "preview" versus "profile" view, > or whatever. > > Does this sound correct, or am I really missing the boat here? How > much of this has been specified at this point? (Maybe this is all > part of OAuth?) > > Thanks in advance for setting me straight... > > chris > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Implementing OpenSocial Containers" 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 -~----------~----~----~----~------~----~------~--~---
