Hi Brian, The short answer is I don't know, on either count. Perhaps if I may explain what I intend to try, and there are false assumptions in my approach, we can expose them now. To date, I've been following various threads on this group, which have informed my understanding and led me to believe that what I describe below is possible. My application is a client-side portal-type framework with infrastructure for layout management, user preference dialogs, persistence of user prefs etc. I want to make shindig/gadget content available within this container. (At the moment I have no requirement for open social data I just want to leverage the gadget infrastructure, although it would be a logical next step to make opensocial services available too).
When I load a 'page' I will know whether this contains any shindig content - I would make a request to shindig for the metadata for any such gadgets. This will give me the info I need to render the chrome and display the appropriate userprefs dialog. I will create the iframe and combine the iframe url from the metadata server with the persisted userprefs that my container has loaded and let shindig populate the iframe. Obviously if my 'pages' consisted primarily of shindig-hosted content, then the calls to the metadata service would impose an overhead that a purely serverside implementation would not incur. This is unlikely to be the case, however - I expect the shindig content to be supplemental to the main content of the app. In addition, I would hope to employ some sort of caching of the metadada if at all possible, so that just as shindig will cache the xml spec, further downstream I would cache the metadata generated from that spec (I stress 'if possible' - I haven't investigated what obstacles this may present). As far as gadget data is concerned - I had supposed that provided I composed the iframe url correctly, then that would provide all the information that shindig required to prepopulate the constructed gadget with the appropriate data ? I have to confess, my experiments so far have been with very simple gadgets which either fetch their own data or don't require any. I had also supposed that I will be able to use the opensocial restful apis (both allow gadgets to use them and even allow the container itself to load data on behalf of gadgets) from the client, should I subsequently opt to expose some opensocial functionality. Authentication is another matter. I honestly don't know how this will work and am hoping that one of the things I will gain from this experiment is a) an understanding of how shindig implements authentication and b) an understanding of how I should implement the same for my own framework. Before now, I have only ever built/deployed corporate apps running behind proprietary/internal SSO systems and adapted each implementation of the framework to the security needs of each app. I very much want to implement an open , generic authentication mechanism for the fw and am hoping my experience with shindig will give me some ideas how to do that. I have seen advice given previously on this list regarding using the metadata service from the client, which was why I assumed this was a valid approach. I'd hate to think I'm sneaking data through the back door, and may see that door closed in some future release. It was the comment that this was not the intended use of this service that set alarm bells ringing here. Sorry to bore you with such a long post, but it would be good (for others beside myself, I believe) to establish that such a 'client-centric' approach represents a valid use (rather than abuse) of shindig services. Thanks Steve heron On Wed, May 14, 2008 at 6:27 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > On Tue, May 13, 2008 at 10:21 PM, steve heron <[EMAIL PROTECTED]> wrote: >>I am also integrating shindig generated >> content into a purely client-side container. > > How are you authenticating users and getting them data? >
