Re: [UM1-coders] cgitelnet interface

[J.P. K. <jp...@he...>]

> I presume that this will also reduce the amount of network traffic
> that it sends. When I tested it from home a few days ago using a
> dial-up connection, it was using 100% of the available bandwidth.

No, the change I made before that, whereby it doesn't send a
<!-- --> on every single loop, but only if it hasn't
sent something in the last 25 seconds did that.

> I presume it is doing a non-blocking read then? Should be
> easy to convert to using select() with a timeout (which will
> also give you your millisecond 'capable' timer).
> 
> If you point me at the code, I'll have a look.

/home/julian/cgitelnet/src/cgitelnet_msg.cgi.c

is the specifically relevant file, but everything under
/home/julian/cgitelnet is relevant one way or another.

I have made that entire tree rw to group uglymug.

If you are looking at it, keep half an eye/braincell on how
to modify the msgsnd and msgrcv portions of the code, which take
parameters from a different program which extracts them from the
html form - I'd like to, in the longer term, allow that to be more
configuration file driven.

> Again, if you want I'll take a look.

Be my guest.  I've merely tidied the code up enough to make it
usable.  All my changes from the original CVS checkedout
code have a comment with JPK in them, so you can search on that
if you want to see what I have done.

> > * However, if noone has any objections I'm probably going to 
> > add it to  *
> > * a subdirectory in the Uglymug source tree.                  
> 
> Go for it, as long as we remember to point out that it has
> a different licence from the main source.

*nod*  Actually I'll wait a bit to see if the current author gets
back in touch with me - I emailed him to see if he wanted any
of the changes that I had made, since thuse far, with the exception
of hardwiring in 'uglymug.org.uk' and '6239' all the changes
I have made have been generic.  

> I can't see us writing additional code specifically for web
> support, especially if we can use someone else's code to do
> it for us.

Well it is a question of efficiency - this isn't an efficient way
of doing it in CPU cycles, but it beats the crap out of the inefficiency
of writing it from scratch.

> Adrian.


Julian

P.S.  For those that care, in order to get this working I installed
autoconf and automake, this will remain available unless we run out
of space.  We currently have 244Mb left on a 1.7G disk, which if memory
serves is smaller than wyrm had?