As Kenton mentioned, capnp doesn't entirely lift the burden of thinking
about the high-level semantics of these things. One possible update
strategy for this particular case:
Suppose your old interface definition looks like this:
interface Server {
listMatchingPeople @0 ListMatchingPeople -> List(Text);
}
Rather than just adding an extra field to the existing request type, you
could add a new method, which will eventually replace the old one
entirely:
interface Server {
listMatchingPeople @0 ListMatchingPeople -> List(Person);
newListMatchingPeople @1 NewListMatchingPeople -> List(Person);
}
New clients will try to use newListMatchingPeople, and at first have to
decide what to do if the server throws an unimplemented exception --
maybe call the old method and do the filtering themselves. As you roll
out servers that support the new method, the implementations could
initially basically be aliases for one another.
At some point, when everything supports the new method, you can drop
the fallback code. It's possible to shuffle the names around to keep
things ergonomic; a common convention is to rename the old method to
something like obsoleteFoo/deprecatedFoo (As a side note, it would be
nice if there was a standard annotation that could be used to tell code
generators that a method should be considered "deleted", so the stubs
for the old method could be removed).
In this particular case, I might also ask whether the interface should
be redesigned for extensibility, and instead maybe do something like:
struct Filter {
union {
age @0 :Text;
emailDomain @1 :Text;
occupation @2 :Text;
}
}
interface Server {
deprecatedListMatchingPeople @0 ...;
listMatchingPeople @1 (filters :List(Filter)) -> List(People);
}
Where servers can reject any filters they don't recognize. It would be
easy enough to add 'and' and 'or' filters later if desired. Hopefully
this would avoid needing to do finicky staged upgrades as often in the
future.
-Ian
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/capnproto.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/155830704542.29432.370503019985896126%40localhost.localdomain.
