Dear Satya and Jan,

Coda plays an important role in the computing infrastructure at Chalmers
University of Technology.

For this reason Chalmers allocates this year 6 months of developer time
specifically for Coda maintenance and development.

The goal is to ensure that Coda keeps its virtues in the long run
and remains useful and usable at Chalmers. We hope also to be able to
lift some limitations.

I would appreciate to hear your opinion on what are the most valuable
changes which ought to be done. It is important and beneficial to everyone
if CMU's and Chalmers' efforts are coordinated and most efficient.

Since about 10 years ago Chalmers runs on both clients and servers a Coda
version differing from upstream, with locally maintained patches. The
main reason is that we depend on transparent support for Kerberos
authentication. The upstream version contains Kerberos-related hooks
but they are unfortunately insufficient for actual deployment.

Until now we strictly kept our changes to be as small as possible and
fully compatible with upstream servers and clients, except for the
additional features.

On the other side, with time we have identified certain issues which
do not seem to be solvable by compatible changes. Unfortunately some of
these issues, if left unfixed, will hit us hard some day. Some of them
must be addressed now, before it is too late.

Probably the most apparent one is the limit on the key length in the
security layer. It is a hard one too, because the limitation is hardwired
in the current protocol.

Would you agree that we face a need for incompatible changes
in the protocol?

If yes, then probably we have a suitable occasion for lifting several/many
limitations at once and possibly for replacing some components.

For the good and for the bad, despite Coda's global nature, its use
is still "concentrated". The majority of the client computers access a
few Coda realms and most often happen to be under the same management
(or strong influence) as the servers of the corresponding realms.

This may allow for a coordinated switch between incompatible protocol
versions even if the clients or the servers can not be made to support
both protocol generations at the same time.

Satya and Jan, you have the best knowledge of the code and of the hard
spots, both in the functionality and in the implementation.

Would you outline your idea of a "Coda ten years later"?
How much of compatibility could the future version preserve?
Given half a man-year of development, how much of that vision would be
achievable and should be aimed for?

What do you think of the possible changes? Which changes are
 - inevitable, to be able to keep Coda's virtues (like security)
 - highly desirable
 - desirable
and what would be the expected man-year cost for taking each step down
this stack?

Of course I appreciate if everyone on the list also tells his or her
opinion.

Such feedback will help me to properly arrange and use the development
resources in the planned effort at Chalmers.

Thanks for creating Coda, a wonderful and unique tool.

Regards,
Rune