> These are two different systems built to solve different problems.
>
> Coda has some inherent limitations (full file caching) which gives it
> the ability to maintain consistency while disconnected.
>
> OpenAFS has other inherent limitations (partial file caching) which
> makes it less portable and does not allow for disconnnected mode - but
> gives it other features like fast open()+seek() on big files.
>
> So while you can solve artificial limitations (say, max number of
> files per directory) or bugs, you can not remove limitations placed by
> design, which enable some features implemented by design.
>
> You can not abandon trains and implement their features in ships,
> because they go different ways. 


Just my two cents...

There's nothing stopping Coda (in theory. I haven't seen the code
relating to this) from implementing both partial and full file caching.
Whether it be a knob between two modes of caching, a switch to require
the fetching of all blocks (with unneeded ones at a lower priority, put
off until essential data is retrieved), or just a program like hoard
deciding what files need to be cached fully, and doing so. I'm not
saying that this should or will be implemented, but it is possible, in
theory. For Coda and AFS.

Who says that no one will invent a method for replacing train tracks
with small, inexpensive canals? or a method for affixing waterproof
wheel assemblies on ships? One feature doesn't necessarily have to
prohibit another.

Unfortunately, I don't foresee this in the near future, unless someone
absolutely /needs/ them and has the resources to implement them, as
there seem to be more (subjectively) important hurtles to jump in the
Coda development process.

-- 
Kris