[cap-talk] Handling upgrade with the Waterken Server (was: A paper on web-keys)
tyler.close at gmail.com
Sun Jan 20 18:22:13 EST 2008
Upgrade is a tough problem, but like other tough problems we've worked
on, like access-control, I think object notation provides a useful
language for expressing solutions. Developing some useful design
patterns, like we have for access-control, is the next major step.
I've got a few that I hope to write up in the next little while, but
I'll outline one of them in this email.
On Jan 18, 2008 6:23 AM, Sandro Magi <smagi at higherlogics.com> wrote:
> Toby Murray wrote:
> > That's very cool -- not least because it takes advantage of the "the
> > object's interface *is* the UI" idea that the Waterken approach makes
> > Waterken implementation but this certainly applies to the old XML/XSLT
> > one.) I think that this is one of the key advantages that Waterken has
> > over all other known capability implementations -- e.g. E, KeyKOS
> > derivatives, etc.
> The one concern I have about "the object is the UI" approach is upgrade.
> Web applications are constantly being refactored, and upgrading a
> persistent object store is a *tough* problem. It's my last unsolved
> dilemma with the web-calculus, and there is little discussion of this in
> the Waterken docs, so if someone has a solution, please let me know. I
> think upgrade should be covered after the requisite "Hello World!".
I think a common theme across many design patterns for handling
upgrade will be to dodge the problem as much as possible. For example,
one approach is to design a set of classes whose sole purpose is to
hold your long-lived state. These objects are kept as simple and
generic as possible. The application's behaviour and user interface is
then implemented in a separate set of classes. Designing these classes
to survive multiple upgrades is just too hard, so we don't and instead
plan to fail here. Failure to upgrade is handled gracefully by
ensuring each user has a capability that can later be used to create a
new application facade on top of the existing long-lived state.
For example, take a look at how I've designed the DNS nameserver for
managing yurl.net registrations:
The long-lived state here is the set of DNS resources for a hostname.
I keep that state as a simple array of variables of Resource objects.
Each Resource object holds the binary content of a DNS resource. All
the user interface stuff is, or will be, implemented in objects that
have pointers to this array of variables. After I inevitably paint
myself into a corner with these UI classes, I've got an escape plan,
in the form of the "extension" capability the user received with the
DomainMaster object that gave them all their initial capabilities to
their hostname. Currently, the object referred to by this capability
has no methods, but is holding pointers to all the long-lived state I
may need to start over with a new UI. When I make use of this escape
hatch, I will just let the other old application objects languish or
die, rather than try to upgrade them.
The above pattern enables major application upgrade. For minor
upgrades, it may frequently be possible to upgrade the current
application objects. For example, Java Serialization supports a number
of different changes. Member fields can be added or deleted and
methods can be added or deleted. The tool Alan referred to is
touch.jar, which simply runs through all the objects in a specified
database and pushes them through the Java Serialization upgrade
process. MarcS and Alan have gotten a fair amount of mileage out of
this upgrade tool.
I've also got some other ideas for handling upgrade and my feeling
right now is that it's a manageable problem, and can be coped with
using techniques similar to those we've used to handle access-control.
Use web-keys for RESTful access-control:
Name your trusted sites to distinguish them from phishing sites.
More information about the cap-talk