Geoff Hutchison writes:
>
> I thought I should post my proposed interface for the
> ExternalTransport class. I won't commit it because I can't build the
> current CVS tree...
I'm very sorry. I'll be online this evening so that we can figure that
out. I've compiled it on three different architectures and I really can't
imagine why it fails for you.
> However, it uses the same script interface as ExternalParser. The
> script receives a URL to retrieve and should give back a formatted
> response:
>
> Field Purpose
> s Status Code
> r Status Reason Phrase
> m Modification Time
> c Contents
> t Content-Type
> l Content-Length
> u URL
>
> The s/r fields are a bit difficult. Should we just require scripts to
> map protocol errors to HTTP codes?
>
> The l field is used in case the script does not retrieve the entire contents.
Maybe a boolean field that tells if the read was truncated ?
t Truncated
> The u field is used in case the script receives an external redirect,
> in which case it should set the s and u fields. The script shouldn't
> attempt to follow the new URL because it may involve a different
> protocol.
f Follow this redirected URL (suggestion, because more explicit)
> Does this seem like a reasonable interface? Should the script receive
> more information? (referring URL and credentials come to mind...)
I have no idea about the way you implemented communication between the
external parser and the main code. A few idea come to mind, and you probably
already have all of them (:-): use generic data structures so that adding a
field is easy, arrange for external parsers to be object modules (using libtool
dynamic loading library) as well as stand alone programs, use a stackable filters
model to communicate between core code and parsers (such as SYS V Streams).
I'll have more focused comments when reading the code.
--
Loic Dachary
ECILA
100 av. du Gal Leclerc
93500 Pantin - France
Tel: 33 1 56 96 09 80, Fax: 33 1 56 96 09 61
e-mail: [EMAIL PROTECTED] URL: http://www.senga.org/
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.