search

fredsa / forplay

Automatically exported from code.google.com/p/forplay
Apache License 2.0
12 stars 4 forks source link

Improve storage API to allow primitive types #33

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Currently the storage API only allows for String types to be added. On a java 
platform this requires casting between primitive types when retrieving values 
which tends to make loading from storage an ugly chunk of code.

This API should be improved to include automatic support for saving/loading 
primitive java types and possibly Serializable types.

Original issue reported on code.google.com by skoru...@gmail.com on 3 Jun 2011 at 1:19

GoogleCodeExporter commented 9 years ago 
When you say "primitive" java types, do you mean literal primitives (i.e., Java 
value types like int, string, short, etc), or Java object types? The former 
would be a trivial change, but the latter is a *big* can of worms, as you're 
indirectly asking for full string serialization of Java object graphs.

This can be awkward enough when running on a "real" JVM (e.g., you have to deal 
with subtle changes to the structure of the object graph when upgrading the 
app), but it's much worse when compiled to Javascript/AS3, because we don't 
have reflection there. In GWT-land, there have been numerous attempts to solve 
this problem, but they all get hairy quickly because of the amount of code you 
have to generate to serialize arbitrary object graphs (not to mention that 
statically computing the set of types that might need to be serialized is 
Turing-complete in the general case).

I don't mean to diminish the importance of the use-case -- this comes up not 
just in Storage, but generally in network communications. But I think it makes 
sense to consider alternative, restricted, serialization forms, like protocol 
buffers, thrift, json+schema. Perhaps we'll need to add a little code 
generation to the mix to make it tolerable.

Original comment by jgw@google.com on 3 Jun 2011 at 2:12

GoogleCodeExporter commented 9 years ago 
By primitive I mean literal primitive which is the main thing I'm after. The 
serialization is more of a nice to have if possible and not too complicated 
kind of request. 

I didn't think about that case of dealing with class structure changes and was 
in fact thinking more in terms of restricted serialization forms like json 
especially for javascript. I can see cases that might come up where it would be 
nice to dump a settings object to storage in 1 call rather than writing 
read/write calls for every variable.

Since the serialization problems require more thought forget about that for 
now, primitives are enough.

Original comment by skoru...@gmail.com on 3 Jun 2011 at 2:41