On Thu, Dec 23, 1999 at 03:41:32PM -0500, Greg Troxel wrote:
>   The problem is actually that we don't have nice `plug-n-play' patches
>   for rpc2 decoding. Our current setup depends on the protocol opcodes
>   (i.e. headers) generated by rp2gen, and the resulting tcpdump can only
>   pretty-print Coda traffic.
> 
> If the coda on-the-wire protocol is stable (it seems to be at the
> moment, but I'm not sure), one could submit the files already
> generated, and teach tcpdump about the port numbers in use.  That
> would be an improvement, even though it might need changing later.

It isn't stabilized yet, we have a couple of things that are very likely
to change over the next few months. Anything that returns a server IP
address, should also return a port number, that way we can run multiple
servers on a single machine without having to use IP-aliases on the
interfaces. Although these things shouldn't affect the used opcodes,
except if we attempt to maintain backward compatibility.

Also ViceID's are probably going to be 64-bits, and I'm expecting
several changes with respect to encryption, at the moment any form of
block encrypted sftp packets cannot be retransmitted at all and the
initial binding sequence is another likely candidate for some plastic
surgery.

>   Ok, I've applied your patch, actually testing ${prefix} first. I don't
>   think we need CFLAGS during the test at all. We are only attempting to
>   link;
> 
> Thanks.  Actually, the test should probably be to include the header,
> use some function, and then link.  That way it will fail unless the
> includes are there too.  autoconf has macros for testing for functions
> in libraries, and this is probably a good place.

I'll give it a try.

> It would be cool if lwp (etc.) install autoconf macros to find
> themselves for aclocal to use.

Maybe, another way would be a simple
    liblwp-config [--version|--cppflags|--ldflags]

Can be a script that is set up by configure. But ofcourse, you would
need /usr/local/coda/bin in your path, or this won't work.

> I realize that going to automake is hard; I meant only to remove
> configure, since it can be generated from configure.in.  I'd be very
> surprised if this caused trouble for people using anoncvs.  (I check
> out things with CVSREAD=t to make emacs vc mode work nicely, and
> running autoconf got me a flame about configure being read-only, so
> the current scheme caused me trouble.  Plus, 'cvs diff' would have
> given me a configure diff, not just configure.in.)
>
>         Greg Troxel <gdt_at_ir.bbn.com>

Already done. I commited that change along with the ${prefix} one ;)

Jan