- From: Richard Atterer <richard@list03.atterer.net>
- Date: Tue, 6 May 2003 23:01:17 +0200
- To: www-lib@w3.org
On Tue, May 06, 2003 at 07:03:32PM +0200, Sasha wrote: > CONNECT - application performs TCP connection > DATA_IN - inbound data are passed to callback > DATA_OUT - outbound data are passed to callback > CLOSE - connection is about to close. Why do you need to put a big libwww layer inbetween there? Is it impossible to filter the data directly? If the requests made by the user to the personal firewall and the requests made by libwww to the net are not directly correlated, I think you'll need to run libwww in a separate thread so it can download whatever it needs, and then somehow send the data to the callback. > if port is HTTP i'm will create a HTTP serve request > instance and pass it to libwww with specal transport class, which > will be able to deal with request (currently i've got very inacurate > ideas how transport streams should look). I don't think you need a full HTTP server here - can't your callback code just use libwww like any other client? > well folks and here are my questions: > is it possible to use libwww in such a way? > i've rather hope so, instead of know how to implement it. I'm not sure - I guess you could make it behave like a HTTP proxy with some work, but I don't really understand why you'd want to use it that way. :) > are there similar projects, which i'm going to do? > could not google anything... IMHO, the only code with comparable functionality is the one in Mozilla. (Dunno about Konqueror, does it support HTTP pipelining?) But there's also libcurl, which is simpler, cleaner and easier to use. > are there any better papers about libwww, than attached documentation? > i mean paper with more pictures, where library design is more > obvious. No - use the source, Luke! ;-) Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Received on Tuesday, 6 May 2003 17:31:31 UTC