Uhm, are you talking as a container developer or a gadget developer?
As a container developer that has to think about scalability, 10k is
already a lot. I consider appdata for small things like game
highscores or similar information.
I would assume that gadget writers, as soon as they need more than
just a few bytes, send their data to their own backend servers using
makeRequest.
As a gadget developer, storing everything (and a kitchen sink) in
application data is cool, yes. :-)
As Chris already said, this is ultimately a decision of the container
provider. It might e.g. possible to adjust appdata quotas if e.g. the
owner of the embedding page or the gadget author is willing to pay for
it (wait, let me file a business improvement ticket for that... ;-) )
Ciao
Henning
On Tue, Jan 6, 2009 at 08:45, 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?
>
> Thanks!
> Dave
>
>
