🚀 go-pugleaf

I have sent Aaron a separate piece of email with more
detail, but have a couple of comments for the whole group.

In article <46131@ogicse.ogi.edu>
nabil@ogicse.ogi.edu (Aaron Nabil) writes:
>peterd@cc.mcgill.ca (Peter Deutsch) writes:
>+In article <46078@ogicse.ogi.edu> nabil@ogicse.ogi.edu (Aaron Nabil) writes:
>+>I'd like to write a freely availiable archie server, preferably one
>+>that can read existing archie databases.
.  .  .
>
>You could try answering your email when commercial
>sites like mine with money in their fists write you asking how
>to set up an archie server. 

Your email apparently got lost, and I apologise for this,
but archie 3.0 is definitely available and now shipping.
Without trying to make excuses, there are a couple of
reasons why this might have happened. Of course, we handle
_lots_ of user-type queries each day so sometimes other
queries get lost in the noise since Alan and Ieach
sometimes assume the other guy answered a particular
letter.  There is currently only Alan working full-time on
the archie project, with me doing more "building of
business" kind of work, plus follow-on projects with our
one employee, so we're spread pretty thin. If ever we
don't answer email for any reason, please don't give up -
try again.

>>... I think anyone thinking of turning an
>>archie-like tool loose on the net should consider the
>>impact that hundreds or thousands of similar programs
>>gathering the same data would have on volunteer information
>>providers,...
>
>No doubt, but that's why I want to be able to read existing archie
>databases.
>
>>BTW, I'm not sure I understand what you mean by "read
>>existing archie databases"?
>
>For example, ans.net has their archie database publicly readable.  Several
>archie sites are mirroring it for their own use.

I now understand - you're talking about the compressed
ls-lR files in the archie listings directories.

We obviosly haven't released any of our parsers (which
filter out error messages and verify that these listings
files are consistent) since they are a core part of the
archie code, and non-trivial programs to get right (the
lack of such a parser for VMS was due to the time it took
us as volunteers to write such a beast). There is such a
parser for the current release and thus VMS host support
will appear as the existing servers convert to the new
code.

Of course, we can't compete with free or subsidized
programming time, but since this code (and providing for
its associated support) is our only source of income we
unfortunately can't release our code to the world. (yes, I
know of the GNU model, but I believe that releasing source
would merely make it easier for someone else to go into
competition with us charging for the support, with us
giving away the last year of our work to set them up in
business. I'm not really convinced that this would be fair
to us).

Anyways, we're still happy to share our experience,
information services model, documentation, etc. We are
currently planning a paper on the architecture of archie
3.0 (once we get a quiet minute or two to look at it) so
those wishing to do something similar can see what we did.
We're also working on several RFCs on information
templates, a quick and dirty guide to Internet tools, etc.
Copies of this sort of material in available from the
machine "archives.cc.mcgill.ca" in the directories under
"pub".



					- peterd