I'm with you there, Matt, direct control of this caching would be ideal - but we don't have it today.
The cached JavaScript solution does require an extra request from the browser, but it's something that works right now. Ah, tradeoffs... That TTL setting is a great idea. It wouldn't work to put the setting in the gadget XML itself, would it? If you have the TTL set to an hour or a day, and now you change it to a smaller value, IG won't see the change until it fetches a fresh copy of your XML. Google would probably have to build a developer control panel where you could log in and set your cache expirations. Or to make it simpler, if you could just log in and click an "invalidate cached copy" button, that would be good enough to solve the update problem. -Mike > From: Matt (Guru) > > I would really prefer an alternative of a "Time To Live" > value in the gadget XML. Just like in DNS propagation, the > TTL value would tell Google how long to cache the XML before > checking for a new one. > > When I release a new update, I could set the TTL to be 0 to > force my gadget to not cache at all for anyone. Any update I > make would instantly be live. > > Once it seems stable, I would maybe push it to 60 minutes. So > if I found a big problem I could have it fixed for everyone > in an hour or less. > > Finally, once it's solid, maybe I move it to 24 hours. > > I think this would be a reasonable way to manage these > caching issues and give some control back to the developer. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iGoogle Developer Forum" 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/Google-Gadgets-API?hl=en -~----------~----~----~----~------~----~------~--~---
