On Nov 24, 10:34 am, Michael Geary <[EMAIL PROTECTED]> wrote: > Matt, you need a better solution that lets you control your own cache > interval. Here's how you can do it.
Thanks for the feedback. I've done something like that before, and I was considering taking this approach again. The thing I don't like about it is that writing content via document.write() is a PITA (especially for a lot of content!), and it requires another request to the server before the gadget can paint anything. Since js is single-threaded, having lots of gadgets using this method might make the screen paint slowly. 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. Matt Kruse --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
