Hi Ivan and all,

I'm very new to coda. But anyway, I very  appreciate this email from Ivan as I'm now more interested to see coda as stable and ready for deployment for use instead of nfs or samba in companies. In documentation (not updated) is stated, that coda is not ready for this.  I look forward to have updated docs and mainly to know, that coda is ready to deploy anywhere.

Thank you all for making coda more stable.

Have a nice weekend,
Jiri


-- 
Jiri Navratil, http://www.navratil.cz, +420 777 224 245

> 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
>