Oops. I replied to the "announcement", and wasn't careful about the reply
address - sorry. Please do comment. I was worried noone cared...... :-)
>1. I hope you can port libwww -- it was designed to port to Mac,
> PC, VM (!), VMS, etc etc as well as unix. The early VM ports allowed
> only K&R C and no unixisms at all, so I hope you can use it.
Actually I did port libwww to Windows 3.1 (16-bit) with winsock and it works
OK. The port was relatively painless (for an old UNIX hack). Re-writing it
was a tough decision. The obvious advantage to staying with it was keeping
up with the fast-paced changes in URI, etc. The problem lies in its
size, complexity, and performance. After a bunch of fooling around with the
line mode browser (also ported), I felt it would burden a light-weight client
more than the disadvantage of "out of sync functionality".
I am an old X-Window-System developer and it was quite common, when building
the commercial X servers, to re-write major sections of the sample
implementation, especially early on (X11R1). That in no way detracts from
the value of the sample implementation, as you can't re-write something
without it first having been designed and written. In otherwords, sample
implementations are critical to good quality commercial products. If I have
one complaint of the X world, it was that too much of the consortium's time
was spent optimizing the sample implementation when it could have been
spent on standards, new features, etc. I hope as time goes on, the
W3 Consortium will keep this in view. It must be hard to hear about
someone criticizing one's "baby", but designing and coding the sample
implementation is the hard part. Criticizing and re-writing it is easy.
I have separated the xxx -> HTML conversion and re-written the access.
With the exception of not handling the recent new FTP URI features, I believe
it is fully functional. The compiled size is about 50K, as opposed
to 200K for (non-WAIS) libwww. It is also noticably faster and is
multi-threaded.
>2. Except a gopher client talking to a gopher+ server still works and
> vice versa. Not so with whois++.
I didn't realize whois++ was not a strict superset. Maybe it should be
a new protocol (notwhois ?) :-).
>3. proxy returning non-HTML streams for eg FTP listings is OK
> for smart cients, but it does have the disadvantage that the
> smartness level is getting quite high: it is difficult to
> idntify exactly what form an FTP dir listing *is* in, let alone
> specify that as a MIME type! But it does allow the customized
> representation to be done on the client.
> A better idea would be maybe for convertion by the proxy so a standard
> attribute-value pair list whose parsing would be trivial, and field
> names standard.
Good idea. But it is still the case that the client will need to be able
to do directly whatever the proxy can do (in the non-proxied environment).
Even a dumb client must still understand raw FTP directory listings.
Therefore, from a client developer point of view, such a proxy feature
doesn't help too much. Hopefully the world will transition to HTTP and
FTP will become just amusement for us old-timers :-).
Mike
------------------------------------
Michael A. Dolan - miked@cerfnet.com
TerraByte Technology (619) 445-9070