[cap-talk] Handling upgrade with the Waterken Server

Bill Frantz frantz at pwpconsult.com
Fri Jan 25 20:27:14 EST 2008


david.hopwood at industrial-designers.co.uk (David Hopwood) on Friday, January 25, 2008 wrote:

>Bill Frantz wrote:
>> tyler.close at gmail.com (Tyler Close) on Sunday, January 20, 2008 wrote:
>> 
>>> 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.
>> 
>> Traditionally these objects are files and directories.  Thus you
>> have described the approach used by Unix, MacOS, Windows etc.
>
>More precisely, the approach used by Unix, MacOS, Windows etc. is a
>special case of what Tyler described. Note however that links in a
>Unix-like filesystem are not capabilities, and cannot directly be used
>to emulate them.

[I think David's comment above is the essence of Jed's comment.]

My point is, for existing systems, the file system is all you have
to handle upgrade.  Whether you are working with a word processing
system, which handles upgrade by being able to read old documents
(files), or a web server which looks at specific directories, and
specific files in those directories to learn what it is supposed to
do when restarted with new code, the file system is it.  In essence,
in these existing systems, upgrade is just a special case of the
general restart problem.

For programmers used to handling upgrade by having a stable disk
format for their data, the whole object cap paradigm is scary.  They
say, "It happens by magic.  What do I do when the magic doesn't
work?  How do I restore a backup?  You've taken away all my system
administration tools, which have saved my bacon many times in the
past.  I frankly don't trust these new tools."

Our experience with KeyKOS was that upgrade was quite difficult if
the long-term data was held in very application specific containers.
It was quite easy if the long-term data was kept in general-purpose
data storage objects (e.g. files).

The reason for orthogonal persistence in KeyKOS and relatives is
that it is easy to reason about security after a restart, not that
it is easy for application programmers or system administrators.
Perhaps a system with a hybrid approach, where changes in the
long-term relations between programs, data, and users is restored
from the last synced copy, and all more ephemeral relationships
(such as call-return), are lost would be a better approach for these
users.  The reason for not doing a hybrid system is that it is a lot
harder for the system developer.  Harder both to build and to
reason about.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032



More information about the cap-talk mailing list