Re: apache-2.0

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

I probably should have mentioned this before, but I think the right
way to do 2.0 is to start with an empty repository.  We don't need
or want the version history -- it just doesn't matter for a complete
rewrite and will cause more problems when the per-file history logs
become unmanageable (as they almost are already in 1.3).

Files in 2.0 should be added one at a time, when they are needed, and
with the most appropriate name and directory to suit 2.0 (as opposed to
just continuing the old names).  Things copied from 1.3 should be added
as they appear in 1.3 and then revised from there.  However, I think
almost all of the initial work will be on the OS/main loop, request
and response data structures, stream-based I/O, and a new API.

....Roy

Re: apache-2.0

[Igor Tatarinov <ta...@prairie.NoDak.edu>]

It might be also a good idea to split files into smaller ones, e.g.
http_main.c is huge now and contains many utility functions that can
probably be moved to other files.

igor

Re: apache-2.0

[Marc Slemko <ma...@worldgate.com>]

On Tue, 27 Jan 1998, Roy T. Fielding wrote:

> I probably should have mentioned this before, but I think the right
> way to do 2.0 is to start with an empty repository.  We don't need
> or want the version history -- it just doesn't matter for a complete
> rewrite and will cause more problems when the per-file history logs
> become unmanageable (as they almost are already in 1.3).

But 2.0 won't be a complete rewrite and any attempt at starting from
scratch would be ill advised, IMHO.  We will never get anywhere.

Whatever we do, continuing the use of most of the modules is a good idea.

> 
> Files in 2.0 should be added one at a time, when they are needed, and
> with the most appropriate name and directory to suit 2.0 (as opposed to
> just continuing the old names).  Things copied from 1.3 should be added
> as they appear in 1.3 and then revised from there.  However, I think
> almost all of the initial work will be on the OS/main loop, request
> and response data structures, stream-based I/O, and a new API.
> 
> ....Roy
>