Subject: CVSup Author's comments on current discussion
To: None <current-users@netbsd.org>
From: David Maxwell <david@fundy.ca>
List: current-users
Date: 05/04/1999 22:05:15
I wrote to John Polstra about some of the issues discussed.
I'll be passing the mailing list info along to him, so he may
join in some himself, in a bit. Meanwhile, here are his thoughts.

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville 

----- Forwarded message from John Polstra <jdp@polstra.com> -----

>From polstra.com!jdp Tue May  4 13:55:01 1999
In-Reply-To: <19990504012412.C2854@fundy.ca>
Date: Tue, 04 May 1999 09:54:56 -0700 (PDT)
Organization: Polstra & Co., Inc.
From: John Polstra <jdp@polstra.com>
To: David Maxwell <david@fundy.ca>
Subject: RE: CVSup protocol standard?

David Maxwell wrote:
> 
> I don't know if you're aware of it, but there has been an ongoing
> discussion in some NetBSD mailing lists for/against the use/promotion
> of CVSup as a distribution method for NetBSD.

No, I wasn't aware of it.  Thanks for letting me know.  In which lists
is it being discussed?  Perhaps I should subscribe to one of them.
BTW, you have my permission to quote this mail back to the appropriate
lists if you want to.

> For: Fast, Good Quality, Modern tool, Greater Choice.
> 
> Against: M3 not available for all NetBSD platforms,
>        Protocol not standardized outside of M3 implementation (no
>               official standard)
> 
> I'm giving a little bit of thought to doing a C version, which addresses
> the M3 issue. However, the other point is a valid one. I'd rather not make
> a C version and then be playing catch up to the M3 version all the time,
> nor would I want to end up diverging into a different protocol.

OK, I'd like to address these two issues individually.  First the
M3 portability problem.  I would argue that a C port is a very
inefficient way to solve that problem.  I don't know how much you've
looked at the CVSup sources, but it is currently 36,000 lines of
code.  That is a _lot_ of stuff to rewrite in C.  Making it harder,
the existing code makes heavy use of language features that don't
exist in C:

    * Garbage collection
    * Exceptions
    * Threads
    * Polymorphic objects
    * Data structures (growable arrays, linked lists, and both
      ordered and unordered maps) provided by the M3 runtime
      library.

This makes it a non-trivial porting effort.  Sure you can fake most of
these things in C.  You could use the Boehm conservative GC, pthreads,
roll your own data structures, fake the objects with #defines and
function pointers, and so forth.  But remember that most of these
approaches would also make your C program less portable.  And when
you were done, you'd have something rather fragile and difficult to
work with.  You could use C++, but that language has its own set of
problems.

If your goal is to have CVSup available on some new platforms, why
not take the easy approach?  Port the M3 compiler and runtime.  It's
not hard to do!  The compiler uses a very slightly modified version
of the gcc backend as its code generator, so it can generate code
for anything that gcc can generate code for.  That's just a matter
of specifying the right target to "configure" when building the code
generator.

The rest of the porting job consists of creating the NetBSD-specific
interface (*.i3) files which correspond to the various *.h files in
/usr/include.  That's a bit tedious, but it's not too bad.  You could
get a good jump-start by copying the FreeBSD versions, and then fix
the differences.  Architectural details are confined to just one or
two of the files, so once you got the OS details right, you should be
able to port to new NetBSD architectures without much work at all.  I
say this based on my experience porting M3 to FreeBSD/Alpha.

If this sounds like a lot of work, please consider:

    * It's a lot less work than rewriting 36,000 lines of M3 code
      into a lower level language.

    * You will have to learn at least a little M3 no matter which
      course you take.

    * A rewrite in C would splinter the CVSup development,
      whereas porting M3 will allow us to combine our efforts.

    * A rewrite in C would gain you ... CVSup.  Whereas, an M3 port
      would gain you CVSup plus the availability of M3 under NetBSD,
      for a lot less work.

> Have you considered issuing the CVSup protocol as an RFC or other 
> standards document, to facilitate its greater use?

I had never given it much thought.  To be fair, none of CVSup's
"competitors" (rsync, rdist, sup) have done this either.  There is an
admittedly terse document describing the protocol details that comes
with the CVSup distribution.  It's in the file "doc/Protocol".

I would like to keep the flexibility to make the protocol better
over time, but as long as the specification didn't hamper that I
wouldn't oppose the idea.

> Would you have any interest/time to 'support' a C version, as far as
> version IDs in the protocol, migration paths etc?

The protocol already includes version IDs, and in fact there have been
16 revisions of the protocol since the first public release, without
ever breaking interoperability between any arbitrary pair of versions.
At start-up the client and server negotiate a protocol version that
both support.

I would hate to see a rewrite come into existence without a very
good reason for it.  It would needlessly double the amount of work
for adding new features, and it would introduce endless sources of
potential incompatibility.  It would make more sense to abandon the M3
version so as to keep the active development on one version only.  But
I would have a hard time getting excited about working on a C version,
because of all the compromises (==> maintainability problems) it
would entail.  I'm not some kind of "Pascal forever" dweeb who can't
get his mind around C.  In fact, this month I'm celebrating my 20th
anniversary as an independent software developer who makes his living
coding in C and C++.  I used M3 because it was the better language for
the job.  I urge you to take that into serious consideration.

Regards,
John
---
  John Polstra                                               jdp@polstra.com
  John D. Polstra & Co., Inc.                        Seattle, Washington USA
  "Self-interest is the aphrodisiac of belief."           -- James V. DeLong


----- End forwarded message -----