Re: BGI-spec 1.4

Simon E Spero (
Mon, 04 Jul 94 18:35:56 -0400 writes:
>(I agree with / understand everything I don't explicitly reply to)
>Hmm... This sounds very Sun specific (I'd be interesting in doing
>this on SGI's IRIX 5, which has dynamic linking like SunOS but a
>different thread library).

Solaris threads are UI compliant, which is very similar to pthreads;
however the actualy mechanics of restarting a server isn't specified
as part of BGI.

>Then maybe I didn't understand your story about restarting... How do
>you actually tell your server to restart?

I use the standard convention of 'kill -HUP pid' to request a restart. However,
that's just me :-)

>My point whas that the mount point argument is unnecessary here. Do
>you not agree?

It may or may not be necessary; the spec could be changed to drop it
and force the cookie to hold the mount_point if the handler wants it.
I'm easy either way..

>What's the point of having two return codes? Why not simply specify
>"0 -- request completed; anything else -- generate HTTP error code".

Just othogonality; 200 is the code for OK in http, so I thought I might as
well allow an application to signal unambiguous success. Again, it's not
something I'm particularly attached to, but it seemed a good idea at the time.

>SunOS 4 and 5 and maybe other systems; it may be a starting point for
>portable synch primitives. Interested?

I have an application framework that I wrote to hit thread details;
I've only implemented it for UI threads so far, although I did have a try
at a posix module - unfortunately, I don't have a machine that supports
kernel level posix threads, so I haven't integrated it into the main-line

>> Yes, and yes. http_error generates a response, and produces an error message.
>> The header for the response specifies "Content-Type: text/html", but does
>> not include a "Content-Length:" field.
>You may be sorry for the Content-Type: text/html header in the future
>-- I'd say just write the response header. Then I can also use it to
>generate a 200 response.

I have a separate function which I use to generate 200 headers, which fills
in all the usual stuff; however, since I'm not yet satisfied with it, I
didn't add it to this version of the spec.

>> Any extra data sent to the socket must be valid html code; the module can
>> rely on the html document being at the start of a paragraph.
>Oops, do I understand correctly that you already generate some HTML
>describing the error?

Yes; the aim is to generate generic error descriptions in the library.
At the moment I haven't properly coded this part, and just have a standard
message ("Error %d - it's buggered, lad"); this will be replaced by something
more useful real soon now. I will probably be adding another paramater to
http_error which would be a pointer to the accept_language variable. However
this won't happen properly until I get a bigger collection of internationalised
error messages (like, for example, Dutch :-)