Just for practice, I decided today to use SWIG to generate wrappers
for libwv. This worked fairly well, and some code is attached.
This allows you to do something like this, in Python
p = wv.wvParseStruct()
print wv.wvQuerySupported(p.fib, None)
wv.wvSetCharHandler (p, wv.char_cb)
wv.wvSetSpecialCharHandler (p, wv.specialChar_cb)
wv.wvSetElementHandler (p, wv.element_cb)
wv.wvSetDocumentHandler (p, wv.document_cb)
My first question is, what functions and datatypes should be exposed to
the scripting language interface? The above sample code uses just a few
functions, which are the functions used mostly by AbiWord, wvWare.c, and
other users of libwv. However, basically everything is exposed in wv.h.
Should the scripting language see all of this? Should it just see the
import functions? What are the important functions?
Second, in the course of doing this, I discovered that wv.h has
declarations for a large number of functions that are not defined in
anything that goes into libwv.a. I found this rather strange. Is there
a good reason for this? Shouldn't they be taken out of the header? 
 a list is attached in undefined_funcs
sam th <sam@...>
On samedi, nov 23, 2002, at 06:58 Europe/Paris, sam th wrote:
> Second, in the course of doing this, I discovered that wv.h has
> declarations for a large number of functions that are not defined in
> anything that goes into libwv.a. I found this rather strange. Is
> a good reason for this? Shouldn't they be taken out of the header? 
Attached is the list of symbols I export from wv.framework so that
AbiWord actually links. If that helps.
 wv.framework is a MacOS X framework that provides wv. Frameworks
are shared libraries that bundles headers and other stuff.... This is
really MacOS X specific. This stuff is currently unreleased.