On Tue, 12 Jul 1994, Eric W. Sink wrote:
> In addition to mentioning the NCSA versions of Mosaic and ours, Spry's
> AirMosaic is still based on libwww 2.09, as far as I know (Chris?). EINet's
> MacWeb and forthcoming WinWeb appear to be based on CERN code. I presume
> they found it necessary to make substantial modifications as well.
> What *actions* can we take to remedy this situation? Given the number of
> code changes that have taken place in the various incarnations of libwww,
> I do not think it is likely that any non-UNIX browser will be able to
> upgrade to 2.17. At the least, it will require substantial effort, and
> we don't want that effort to be repeated when 2.18 comes out.
I think it is fairly obvious that all the changes that were made to these
libraries were not coordinated correctly with CERN for their codebase; on
the other hand perhaps they were and CERN didn't put them in and still
expects us all to make these changes everytime they put out a new library
(Lou had mentioned this once as a reason why we were stuck with 2.14, but
then I wouldn't approve all of the Lynx hacks either).
Sure, all the clients chew up the code a bit for their specific purposes,
and some lose large chunks of it, but what should have been done in order
to keep everyone consistant is to give the modifications made to their
library on your specific systems to them for their review and future
inclusion while trying to keep as much as the common code as possible.
If this isn't done, then don't expect to be compatible.
After submission, if the mods aren't included into the libwww and a
compliant solution isn't found by coordinating with CERN, then perhaps it
is best to split from CERN and do it yourself. This goes against the
purpose of this mailing list and I am assuming, mind you, that CERN is
willing to bend over and comply to our wishes and modifications. I am
very skeptical about CERN having the manpower required to do this.
CERN, is it feasible?
Is this the purpose of the libwww and of this mailing list?
If this doesn't happen by either our faults or CERN's fault, this idea of
a common code base is going to fail repeatedly.
Perhaps we, the developers, need a very specific set of coding conventions
when modifying the CERN library to keep it unfragmented; and therefore
allowing us to make consistent code contributions to CERN for easier
inclusion. What would these conventions be?
I am trodden soil.
Dust covers my face.
Soles crush my nature
Revealing a hard empty space.
Garrett Arch Blythe (913)864-0436
User Services Student Programmer/Consultant
University of Kansas Computer Center