Re: Features...

[Jan-Henrik Haukeland]

Martin Pala <address@hidden> writes:

> Christian Hopp wrote:
>
>>1) Generic protocol test...
>>
>>   if failed port 1234 [{expect|send} "string" [{expect|send} "string"] ...]
>>
>>   Actually it is quite self explaining...  for every "send" the
>>   "string" is sent through the connection (w/ or w/o ssl), and for
>>   every "expect" the return is read and matched against the "string".
>>
> This seems good :) Maybe only instead of "send" we can use already
> present "request" word, which serves for the same purpose in already
> implemented protocol tests (such as http).

(I think request should only be used for requesting a document entity
from a server, while expect|send is more of a protocol test.)

Yes, expect|send seems like a good idea, because it's a way to
implement a protocol in the configure file, instead of implementing it
as a protocol C-module.

You will probably need to use the keywords send and expect because not
all protocols will send you a greating, e.g. HTTP.

if failed port 80 send "HEAD / HTTP/1.0" expect "HTTP/1.1 200"

But implementing this will (probably) quickly raise a request for
supporting simple reg. exp. in a string for this to really become
useful.  Consider the above http test, here the answer from the server
could either be "HTTP/1.1 200" or "HTTP/1.0 200" where both are okay,
so as a user I would really like to do something like this:

if failed port 80 send "HEAD / HTTP/1.0" expect "HTTP/1.[01]{1,1} 200"

Maybe the gnu regexp package could be used, but I don't think that we
should support regexp in the first version :)

>>2) A watchdog thread... (I think I have mentioned this hidden
>>   somewhere in a mail some days ago)

I'm ---1 for implementing a watchdog thread, because it adds
complexity without contributing much of value. If I understand you,
you suggest that such a thread should be used to monitor deadlock
situations. This is not an easy task to do and besides a dead lock is
actually a bug (in my book) not something that should fixed in a
watchdog thread. Besides only the thread that locked a mutex can
unlock it and you will need to signal the locking thread someway and
so on. It's messy and complicated stuff. It's not a coincidence that
many big applications simply runs in one thread and that it took a
long time before apache supported threads (and still doesn't do it
well).

>>3) Auth via htpasswd...
>>
>>   auth /path [user, ...]
>>
>>   where "path" is the fq path it the corresponding htpasswd and
>>   "user" is a user grant access.  If user is omitted all users do have
>>   access.
>>
> This can be usefull :)
>
> Martin

Agree.

-- 
Jan-Henrik Haukeland