Thanks everyone for your inputs. I was speaking as a gadget developer for the moment :-) We have two separate deployment strategies: 1) Hosted in our own container via our own Shindig -- here we control the container and use our own Oracle/MySQL database for persistence, so there is no issue 2) Hosted on a public site like iGoogle -- here we do not control the container and are subject to the container persistence limits
I suppose we were (naively) hoping that we would be able to use gadget persistence to cache previously-retrieved application data, thus reducing the load on our app server during simple page reloads and the like. That's why I was investigating potentially Deflating the data or employing some other kind of compression, though with only 10K per gadget*user, even that probably won't be sufficient. One point of interest, though: > Remember that if your app is installed by 20M people you're looking at around 100G of storage requirements for your app alone. So, ok. Gmail has, say, 90 million users. Each user has a >7GB quota right now. That's a 600 petabyte (what what?!!) storage requirement. Suppose that (realistically) the average user is consuming, say, 50MB (sure, Google can compress the text, but not so much the pictures, plus they surely keep backups). That's still 4 petabytes of real storage. So if iGoogle also accumulates 90M users like Gmail and each of them puts 10 gadgets on their page, iGoogle can allow over 4MB per user*gadget before the iGoogle persistence storage requirement matches Gmail! I just thought it was interesting, is all. -Dave
