> Oh OK.  Actually, I haven't heard of anyone using inactivity watchers.
> Maybe they should watch a group of watchers instead of event
> priorities...

Watching of watchers sounds really interesting!

> > could the number of screen lines be controlled? As well as the length of 
>descriptions displayed?
>
> I wish I could auto-detect it.  I spent some time trying to figure it
> out but it seems impossible.  At least I can add manual override.

This would be fine and sufficient (this is a development utility), at least for the 
descriptions.

> > The regexp feature is
> > really useful but does not work for "/." (tried to reset the default). 
>"/interface|idle"
> > is not accepted as well
>
> It is restricted to alphanumerics.  I don't want to allow fancy stuff
> like (?{ ... }).  Does anyone know what is reasonable to allow in a REx?

I do not know such rules and found none in my Perl books (I do not own Friedls regexp 
book, may be
there ...). But - in my opinion - is it really useful to restrict a user of such a 
tool? I think no
real server should open such a port. It should always run under developers control. If 
someone can
suspend running watchers and change their priority at his will, what worse could he do 
with regular
expressions?

On the other hand, possibly the Safe module provides something here, but I'm not 
familiar with it.

> > ... The "t" control accepts only certain values (e.g. second value
> > 100 becomes 120, 150 becomes 180, but 54 and 39 work ...).
>
> Yah, that's just how the stats are collected.

Ah, ok. Possibly a short doc note to avoid confusion ...?

> > The command line should be restored after a screen refresh for
> > someone typing a longer command or regexp ...
>
> That's a side effect of using telnet as the client.  I don't know of a
> work-around.

So don't I. If you refresh the screen, the command line contents is still under the 
(telnet) clients
control, so the server has no access to it, I assume ... hm!

> > Nevertheless, these are about 10 levels so I think this should do. Honestly 
>spoken, the
> > idle split is not completed yet so I'm not absolutely sure. But I think it should 
>work
> > (for me (now)).
>
> Hm.  I don't want to change anything until you are sure you need it...

So let's see first what the currently running debugging and ..::ProcessTop sessions 
will show, and I
will ask again for these new levels when I see no other way to solve the load balance 
problem.

Greetings and thanks for your help

                        Jochen

Reply via email to