On Sun, Jun 03, 2001 at 11:14:57PM +0930, Brett Lymn wrote:
> According to Steve Wray:
> >'Will removal of debugging code & routines be feasable and will this
> >cause any incompatibilities with prior versions?'
> 
> I cannot answer any of those questions - I am not on the Coda team and
> they really need to be answered by someone who knows the code.

I do know that asserts in the older parts of the code are actually
calling functions that do useful stuff. Disabling debugging, and thereby
removing the code in assert statements WILL break things horribly. Most
of the asserts that are triggered are simply 'missed error paths' and
disabling the assert won't make the code work correctly.

> >What I was suggesting was taking what has been learned from the experiments
> >with coda and building on it.. evolution, but a new species, as it were
> >;)
> >distinguished by incompatibility much as real species are!
> 
> Could it be time for Coda 6?  Jan?

I've thought about that many times, and so did Peter Braam. Peter spun
off Intermezzo, which wants to achieve 90% of the Coda functionality in
10% of the code. The result is definitely interesting, more
functionality was moved into the kernel. The userspace code was
completely written in perl, leveraging off the better abstractions of a
higher level programming language.

In any case, a rewrite from the ground up is a lot of work, first of all
LWP needs a more 'modern' interface, fast mutexes, semaphores, condition
variables, and events, similar to the Java and Python thread
abstractions which map nicely on top of POSIX and NT threads, which at
some point then might replace the existing LWP stackbashing code. Add in
a sprinkle of higher level building blocks like (message) queues,
read-write locks and the typical nonblocking wrappers for select, sleep,
read, and write.

Then RPC2, many of the existing limits and instabilities are indirectly
a result of RPC2/SFTP. The fact that Coda is unreliable on ADSL links,
lacking IPv6 support, poor encryption. Probably building an RPC2 like
library on top of TCP or SCTP will avoid 'reinventing the wheel' too
much. But we really need some of the features of RPC2 that are not
available elsewhere, so using existing Corba or SUNRPC interfaces is
probably not possible.

RVM is actually reasonably usable and has few real limits (except for
the 32-bit address-space), but it could need at least benefit from a
different memory allocator that is more fragmentation resistant.

Coda clients and servers are a lot of work, and it's the details that
kill you (the last 1% is 99% of the work). So for now I'm trying to
improve the system by doing many smaller rewrites for parts of the
existing code.

Jan