Subject: On the future development of wu-ftpd

From: [email-masked] (Stan Barber)
Date: Sat, 6 Dec 1997 01:46:42 -0600 (CST)

It is certainly my intention to continue to support wu-ftpd as my time 
permits, but perhaps that is just too slow a pace for many of you who want to
see a number of new features added before all the bugs are stomped. My desire
is to stomp the bugs in the current server before we rip it apart to add new
features. The two goals work against each other with the way the current
server is constructed.

It is my plan to work towards a release of 2.4.2 followed by an 
autoconfiguration version of the same server which I will call 2.4.3. 

After that, I had planned to significantly change the server in many of the
ways the apache team overhauled the NCSA server. At that point, I was going
to suggest that a project like apache be organized to provide modules for
that new server that might implement some of the features folks want. That 
future (in my time line) was to start next year in the summer. The first
release was to be a new basic server that would be compliant with the FTPEXT
documents and would have a new API through which folks to build modules to 
hook in new features. This server would not implement everything in wu-ftpd
at the first release, but would build up features on a module-by-module
basis. At that point, my job would be to maintain the basic server and
perhaps house a module repository (with appropriate mirror sites) and look
to others to build and maintain modules. The biggest help to me in making
that happen would be to define the API as well as the basic feature set for
the basic server. 

For those of you who can't wait for those developments, I would suggest you
organize a project to take the 2.4.2 beta 15 server and release something
that might be called release 3.0 or might have an altogether different name.

---

From: Kent Landfield <[email-masked]>
Date: Mon, 8 Dec 1997 11:01:10 -0600 (CST)

Ok. Time for some clarifications...  First, this is what I wrote.

Kent Landfield wrote:
= I have some serious concerns about the way the community is approaching this
= area.  There seems to be multiple camps producing FTP related works that are
= not communicating with the others.  Because of that we are seeing the 
= beginning of splintering of FTP capabilities.  Something needs to happen or 
= we may see the end of a "Fully" functional FTPD that is available in source 
= form. 
=
= What do I mean ?  If there is not an effort, in much the same light as the
= apache or linux folks, to incorporate these new features then the only 
= version of FTPD that you will want to run in a production network is one
= you have to pay bucks for. The free versions will not have the neat and 
= nifty features that management sees as a checklist item. I'm sick of that 
= approach.
=
= Wu-ftpd was developed to better the foundation of the net (NSF grant funded 
= development).  Because of that we have all benefited.  What would it be like
= for the smaller sites if there wasn't an effort such as Apache and you had 
= to buy your web server, your mailers, your ftp client and server software, 
= your PC operating systems, etc. ?
=
= I propose we need to address this on this list soon or watch the wu-ftpd
= become just a footnote in Internet history.

I wrote this out of frustration that the RFC2228 folks did not seem to be 
working with the FTPEXT folks, with the pace of FTPEXT (which seems to be 
picking up), with another currently publicly closed effort that is underway 
to develop new features for FTP that they plan on "releasing to the world
as an RFC" (their words not mine) and with the pace of new enhancements into 
wu-ftpd.

And before anyone gets the wrong idea here... I like Stan and I'm glad that
he stepped up and has contributed the work that he has.  We are all better
for it.  If you have any doubts about the sincerity of that, go look at the 
Resource Center.  Various pages have said the same thing for nearly a year. 
There has been no change in my view of him or his efforts (from which we have 
all benefited).

Stan Barber wrote:
# It is certainly my intention to continue to support wu-ftpd as my time 
# permits, but perhaps that is just too slow a pace for many of you who want to
# see a number of new features added before all the bugs are stomped. My desire
# is to stomp the bugs in the current server before we rip it apart to add new
# features. The two goals work against each other with the way the current
# server is constructed.

We are all buzy and I know that you do this on your own time much like the
rest of us. Time is sometimes a very short commodity when we need to eat.
I understand that and so do the others.

The problem I see is by the very nature of what we are talking about we will
generate more bugs. :) That said, I don't see this impacting wu-ftpd at this 
point. What you are doing is in line with what I have in mind.

We are going to need to do some setup work before we are ready to start a 
real development effort.  To just get started we need to:

   * Review of the current code structure with suggestions as to its 
     reorganization to support module additions,

   * Document an API to allow easily added feature modules,

   * Examine of the feature set of emerging functionality to be added,

   * Determine which features should be developed in parallel or in sequence
     and in what general order,

   * Setup systems from a baseline, development and mirror perspective,

   * Setup administrative agreements as to how to decide what goes into
     the baseline and when it is ready to do so,

   * ...

A setup following the Apache model doesn't just happen overnight.  It will
take some time just to get to the point where we can begin to seriously 
look at changing a line of code.  This is what I was talking about when I
said we need to address this.  Without starting the setup work, the rest
just won't happen....

# It is my plan to work towards a release of 2.4.2 followed by an 
# autoconfiguration version of the same server which I will call 2.4.3. 

Don't slow any development down because of this.  The two should work
well in parallel.

# After that, I had planned to significantly change the server in many of the
# ways the apache team overhauled the NCSA server. At that point, I was going
# to suggest that a project like apache be organized to provide modules for
# that new server that might implement some of the features folks want. That 
# future (in my time line) was to start next year in the summer. 

I agree that this is the type of effort that we need but waiting until next 
summer just to start the setup and examination process seems a bit far out
when the only real changes you plan to make to the code are bug fixes and 
and automated configure/build setup.

#                                                                The first
# release was to be a new basic server that would be compliant with the FTPEXT
# documents and would have a new API through which folks to build modules to 
# hook in new features. 

This sounds like a good starting point to expand things.

#                       This server would not implement everything in wu-ftpd
# at the first release, but would build up features on a module-by-module
# basis. 

Ouch.  This is not what I'd like to see.  I would not want to field something
just to trade one set of functionality for a different set and then wait a 
year to get back to where I was 12 months before. The work of the FTPEXT 
should be be phased in over the subsequent months since there are different 
documents describing different extensions.  That's what I meant above by 
examine and prioritize new enhancements.  Personally, I doubt most current 
wu-ftpd sites would want to go backwards and they would not field the new 
server.  This would splinter the community even more.  What I and others want 
is what we have now plus the new capabilities.  Until we could do that I'd 
vote not to release it. (And you're right, the module approach is the best 
approach.)

#        At that point, my job would be to maintain the basic server and
# perhaps house a module repository (with appropriate mirror sites) and look
# to others to build and maintain modules. The biggest help to me in making
# that happen would be to define the API as well as the basic feature set for
# the basic server. 

I really don't care where the baseline is housed. I am looking at the process
and the results that are running on systems across the net. Foundation, 
Features and the Flexibility to implement them on a timely basis is what
we need to put in place. (My 3Fs. ;))

# For those of you who can't wait for those developments, I would suggest you
# organize a project to take the 2.4.2 beta 15 server and release something
# that might be called release 3.0 or might have an altogether different name. 

This is not going to happen correctly overnight.  This will take time to
setup; but we have to start now.  People willing to make a commitment to the
project have to be located.  The internal architecture of the server and
the API do not happen overnight, much less get documented.  These two efforts,
the current wu-ftpd and the foundation for ngwuftpd (next generation wu-ftpd)
need not be at odds with each other but can be in sync.

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: [email-masked]             http://www.landfield.com/
Email: [email-masked]                   http://www.nfr.net/
Please send comp.sources.misc related mail to [email-masked]
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/