Re: Inconsistent libwww (bug?)

Kevin Kenny writes:
> "Mihai T. LAZARESCU" <mihai@ccmserv.polito.it> utters:
> >I tried to add the html-to-plain conversion facility to w3c (ComLine)
> >but the linker complains:
> >ld: Undefined symbol
> >   _HText_beginAnchor
> > [... et cetera...]
> 
> The missinbg functions are callbacks from the HTML presenter.
> The way that the library is structured also makes it impossible to
> make a shared library out of it.

Actually it doesn't :-) Even though the Library is compiled as one big static 
library under Unix, it is not organized as such. This becomes clear if you 
have a look at the windows version which is split into a set (more than 10) 
DLLs. Each DLL has a function on its own, for example the HTTP protocol 
interface has its own DLL called wwwhttp. In fact, all the WWW*.h include 
files describe an "interface" and you can see a full list at

	http://www.w3.org/pub/WWW/Library/User/Guide/ 

Only two of these interfaces are required in order to use the Library:

	- The basic utility interface with memory containers etc.
	- The core interface which is basically a registry for all the other
	  interfaces.

As SGM/HTML/HText is also an interface, then the application does not have to 
include this if it doesn't want to use it.

> Henrik, would it be possible to replace these with pointers-to-functions
> that the user can fill in at initialization time?  In my private version,
> I've added the following HTextCallback.c module.  It would also cure
> LAZARESCU's problem, since the missing routines are not called at run time
> in the scenario that the message describes.

Thanks for the patch Kevin - I really appreciate this and also I would like to 
encourage you all to send in patches so that I can put it in the code base :-) 
You can find the patch page at

	http://www.w3.org/pub/WWW/Library/User/Patch/

I am currently adding a registry for adding content encoders and content 
transfer encoders. One encoder that I want to add is the chunked encoding from 
HTTP, but this will also provide the possibility of adding zip, compress etc. 
in exactly the same way as content types are handled through converters now.


-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Monday, 15 April 1996 13:46:39 UTC