(Illustration by Gaich Muramatsu)
> 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. -- KrisReceived on 2005-08-15 13:34:28