On Tue, Jan 6, 2009 at 8:45 AM, Citron, David <[email protected]> wrote:
> Hi! Given that many containers (e.g. iGoogle) only allow 10K of > persistent storage per Gadget*User, and given that 10K is not > necessarily a huge amount of space (depending on your gadget), I was > wondering if there was any proposed strategy to compress persistent data > prior to storage. > > Client-side data compression is possible, of course, but there are no > standard JavaScript compression libraries that I could find, leaving the > options to: > - write my own JavaScript implementation of DEFLATE > - use an embedded Java applet to do DEFALTE (heavy!!) > - ? > > Server-side compression via zlib is easy enough with a custom Guice > module, but when a gadget is hosted on iGoogle/Orkut, etc. then the > server implementation is out of the control of the gadget implementer. > > What's the current recommendation? "Persist less"? :-) > > Are there plans to include some kind of data compression as a part of > the persistence infrastructure? If you can handle it, I'd suggest storing the data on your own server and accessing it through makeRequest. Most big apps are already doing this. A lot of apps that can't run their own servers for whatever reason are using s3 or app engine for this and seem to be fairly happy. Otherwise, yes, what you've already said is pretty much what you're stuck with if dealing with a container with a low appdata limit. I wouldn't expect much more than 10-20K per user / per container. Remember that if your app is installed by 20M people you're looking at around 100G of storage requirements for your app alone. > > Thanks! > Dave > >
