Hi Waldemar, There's nothing in OpenSocial that prevents you as a container from doing this. Actually, MySpace uses a similar approach, where gadget developers have to manually press a button to have MySpace fetch a new copy of the gadget whenever they want an update to happen. There's some advantages to this approach, chiefly that it allows MySpace to review all changes to a gadget, so that developers can't upload an innocent gadget and then change it later on to become spammy or malicious, etc, without a review. Even if you do not save a persistent local copy of a gadget spec to your server, Shindig has caching built-in, so it effectively stores a copy of the XML for a period of time. Most containers wouldn't want to fetch the XML upon each request (think of the load that millions of users fetching the same XML file would put on a developer's server!)
Many containers also perform rewrites of the gadget code for various purposes, so don't be worried about that either. For example, orkut rewrites links to images to be hosted on a proxy, combines CSS and JavaScript files, etc. I believe that most of this functionality is implemented in Shindig, so you may want to consult the Shindig mailing list for more information on their rewriters. Hope this helps, ~Arne On Dec 5, 10:05 am, Waldemar <[EMAIL PROTECTED]> wrote: > Hi. I would like to ask you something regarding the nature of hosting > gadget's xmls... > > We are still figuring out the internal aspects of opensocial, right > now we are using shindig(php flavor) to add opensocial support to a > social network site, initially we intend to control which applications > users can add (based on the allowed features from the server) so users > can not add any application from it's xml url but by choosing them > from a collection. > > We are also thinking about grabbing those xml files from their > original sites and hosting them on our servers (because of fear the > original site may not be available occasionally, although if this case > url-type apps wouldn't be available anyway)... so the same idea came > for hosting thumbnails, screenshots and icons (parsing the app's > xml)... then came the issue of hosting locale's xmls and how to cope > in serving them by using proxies without modifications to the original > xml file... > > Maybe we are getting off the trail by adding, modifying or even > corrupting things opensocial is not supossed or intended to do... so I > would really appreciate if you can give us some advice on this, either > we have to keep a limit to this approach, go on, or completely rely on > other sites content. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenSocial Application Development" group. To post to this group, send email to opensocial-api@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-api?hl=en -~----------~----~----~----~------~----~------~--~---
