Hello Troy and all!

It could be fun to use cachefs and have a non-blocking open(),
feel free to go ahead and implement :)

On the other side both things make deployment on multiple platforms
more painful and as such slow down Coda development and acceptance.

None of them changes the fundamental features of Coda, just relaxes
_some_ limitatins in _some_ cases, making it more complex and less
understandable and manageable.

We already have other, possibly more important issues to solve.
We have rvm -- server file number limit -- problem,
directory size limit, we have hoarding that does not scale,
no cryptographic protection, we deploy slow old protocols...

I can reliably trigger bugs in the newest out-of-the-box Coda clients
(the best available as "standard" is for FreeBSD 5.3, Coda 6.0.6)

We are almost there - but not yet - in fixing the kernel interface
so that it would work the same on all platforms.

I think the above are much more pain in the [beep] than slow open()
which would open a big can of worms...

Coda has already a niche where it _is_ useful, with its features,
given reasonable implementation. You are discussing new features,
but there will be no Coda deployment if it does not fulfill the current
"promises"...

My 2 c, as a reminder of priorities balancing :)

Thanks for discussions and contributions,
and happy Coda-ing!
--
Ivan