- From: Rainer Klute <klute@nads.de>
- Date: Tue, 30 May 1995 18:26:53 +0200
- To: mattf@cac.washington.edu
- Cc: Multiple recipients of list <www-lib@www10.w3.org>, "Rainer Klute" <klute@nads.de>
>I am having alot of trouble getting started using libwww. Specifically, >what I want to do as a starting point is to hook up the NCSA HTML widget >with the libwww code for retrieving html. I.e. feed a URL into libwww, get >back a bunch of HTML, and put that into the HTML widget, and have it get >displayed. Seems like it should be simple, but I am getting lost in the >documentation. The problem with the documentation is that there is something at a very high level which gives you an overview of the Library, but when you want to dig further into it you are immediately on the lowest possible level: the source code. And some documentation useful for application programmers who are already familiar with the Library. The middle-level, the glue between overview and source code is completely missing. It should have simple examples and should not hide everything within complicated details as the line mode browser (W3C's example) does. Therefore you have to go The Hard Way. >I have made some progress, but have some major questions. > >1. In numerous places the docs say you should "overwrite" various > modules if you have your own HTML parser, but I can find no > information about what is meant by this, or how it should be done. > > I was able to define dummy stubs for the various HText_* functions > to get my program to compile. Then instead of trying to replace the > HTML module, I set up a request structure using WWW_HTML as the > output format. Is there anything wrong with doing it this way? Do I > really need to "overwrite", whatever that means? What you did was "overwriting" the predefined modules. However, this should really be done in an object-oriented manner! There should be a display class with where you could hook in your actual methods. But that's a problem of the Library's design and not your fault. >2. I think I am missing something really obvious and basic about the > way streams are supposed to work. What should be in the > output_stream field of my request? I just want to get back a string > full of HTML to drop into the HTML widget. I got it to sort of work > by using pipe(), and passing in the write-end to HTWriter_new, then > reading off the other end, but pipes really are not meant for use > in a single process, and I think the program would block if more > than 4096 bytes got written to the pipe before I could read it. > > I also have gotten it to write to a file, which I could then simply > read off the disk, but that does not seem efficient. I started > looking at HTSaveAndCallback(), but the comment in the source > recommends not using it. > > Do I need to use a AF_UNIX socket or something? Or should I just go > ahead and use two separate processes and a pipe? Hm, I don't know the details of the HTML widget, but in a streams-oriented design it should be implemented as a stream and have methods for receiving chunks of data from an input stream. Or you should setup a stream which receives the chunks and implements the interface to the widget. However, as long as the widget wants just a single string you'll to collect all the data before passing it on to the widget. A better solution would be to improve the widget. Disclaimer: I didn't look into the HTML widget's for a year or so. >4. Is there any problem in general linking libwww with an X/Motif program? > Mosaic does it, so it must be possible. But it seems to me that there > could be interence, for example you are supposed to use XtMalloc and > XtFree instead of malloc() and free() everywhere in a Motif program. That shouldn't matter. Best regards Rainer Klute Dipl.-Inform. Rainer Klute NADS - Advertising on nets NADS GmbH Emil-Figge-Str. 80 Tel.: +49 231 9742570 D-44227 Dortmund Fax: +49 231 9742571 <http://www.nads.de/~klute/>
Received on Tuesday, 30 May 1995 12:27:15 UTC