> Is the concept of versioning something that belongs in the core GWT
> RPC code, or is this something better suited for an external library?
I have a design wave going on about how to add this to the new RPC
implementation. Here's a cruddy copy-and-paste of the current state
of the document.
The crux of the schema-skew problem is that Java objects don't have
support for optional fields in the way that protocol buffers do. An
Object either declares or inherits a field, or it doesn't. Moreover,
there is a difference between not having a value for a field and not
knowing about the field (the difference between undefined and null).
In this document, I'll refer to client and server CLs. What I'm
really referring to is the version of the RPC object schema. It is
likely the case that perforce CL X and X+eplison have the same object
schema, but CL is easier to write.
Assumptions:
The server code rolling forward is more common (in terms of potential
user impact) than the server rolling back. That is, a client is more
likely to see a server going from CL X to X+1 than it is to see a
server going from Y to Y-1.
Version skew support is an opt-in feature, because the developer has
to agree to semantics that are different from regular Java
serialization. Types that support version skew must still be usable
with legacy RPC.
Both client and server must have identical "Required" fields. This
allows the developer to guarantee a minimum level of schema
compatibility.
"Optional" fields need not be present on both the client and the
server. It is acceptable for a field to change from Required to
Optional or vice versa.
The server has access to gwt.rpc files for all permutations that might
still be running. Retention policies are specific to the app (e.g.
from two pushes ago for online apps or two months ago for apps with
offline support).
Because of the static nature of the Java code, it is possible to
analyize the server schema and compare it with the saved ClientOracle
data to determine which permutations a given RPC service is
incompatible with, either as a presubmit check or as a
garbage-collection measure.
The client must be able to preserve newly-added, optional fields so
that any object sent by the server and merely echoed by the client
will be returned to the server with the same data. The server is
under no obligation to preserve unknown, optional fields sent by the
client.
Implementation details:
For any object that is not trivially serializable, the client
presently consults the RpcProxy's TypeOverride object for a list of
field names to serialize. Trivially serializable types are
serialized with a for-in loop to save overall JS code size, but these
could be changed to using a list of fields. When the server sends a
type with new, optional fields, the object will be created with the
extra fields assigned an expando hung off of the Object::expando
field, which is accessible through the WeakMapping client API.
Essentially Object::expando['rpcExtraFields'] = {'field1' : value,
'field2' : value, '_fieldNames' : ['field1', 'field2']};
Jul 17
me:
This is an extension of Dan's JDO magic-field support.
If the server does not receive an optional field, its value will be
null if it is a nullable field, or the default value if the field is a
primitive type. The default primitive values can be overriden on a
per-field basis via the use of an annotation.
If the server's schema does not have an optional field that is known
to the client (as indicated by the ClientOracle), it will synthesize
an appropriate value in the return payload.
Visible API changes:
A new, RPC-specific annotation will be created to designate optional
fields, called @Optional. This annotation may be specified on fields,
types, and packages to designate tha the field, fields in the object,
or fields in the objects in the package, have the optional semantic.
An @Required annotation will be provided to override wide-cast
@Optional annotations.
--
Bob Vawter
Google Web Toolkit Team
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
