🚀 go-pugleaf

On Saturday, in article
     <20120922.0225.12090215snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" wrote:

>         - hi; in article, <20120920.1355.933016snz@twoplaces.co.uk>,
>          simon@twoplaces.co.uk "Simon Turner" pondered & pronounced:
> >[This is going to be rather long: apologies in advance.]
> [still fairly long...]
> >                         "ppint. at pplay" wrote:
> >>        simon@twoplaces.co.uk "Simon Turner" commented & explained:
> >>>                       "ppint. at pplay" wrote:
> >>>>    (following article, <20120914.2213.12090153snz@i-m-t.demon.co.uk>,
> >>>>                         in which i wrote):
> 

[big snip]

> >>>[...] (b) implement Pete's ESMTP SIZE restrictions for
> >>>POP3 as well, which would allow you to set a size threshold above which
> >>>messages wouldn't be downloaded.
> >> 
> >>      - will the latter reject messages above the threshold, or leave
> >>      them uncollected?
> >
> >It could (and, I think, should) do either: I can see it being useful for
> >quick downloads with a low threshold, just to see if that expected (but
> >short) mail has come in yet, and leave the main download (with a higher
> >threshold) for later; and the *really* big ones could be left on the
> >server to be collected at the weekend.
> 
>         - *nods*  having the choice would be more flexible;

After a suggestion from Pete, I think it needs three settings for what
to do with large messages: 0 = leave on server; 1 = delete and send DSN
to sender to explain; 2 = delete without informing sender.  Default = 0.

> >[...]  (All will become clear below, if you can wade
> >through that far!)
> 
>         [...]
> 
>         - wade in [the] water ? - it's a _long_ time since i did that
>         (and it was ramsey lewis' track, anyway).  but here we go,
>         slithering and sliding on, living the timeless life... (- [a])

8-)

> >>      - nor, when an ftp session ends (which it used to, sort of -
> >>      formerly, it'd re-set to another (the next-highest numbered,
> >>      iirc) session.
> >
> >Are you sure KA9Q ever did this (resetting the "active session" marker
> >to the next-highest-numbered session when the currently active session
> >ended)?  The GremNOS code certainly doesn't behave that way, although
> >it's possible to persuade yourself that it does (I managed to persuade
> >myself thus earlier, before I'd understood how it really works).
> 
>         - no, gremnosceri haven't - leastways, not so far as i can
>         recall since your first pplt (& the lite & large from which
>         it was derived); but yes, i'm sure - 216d and other versions
>         i've used since getting my very first ever (tinypcclone) 386
>         i-m-t with its massive 42MB hard drive - it was a noticeable
>         difference to which i took a little time to adjust, so "i'm
>         certain (but i suppose i could, just about, be wrong)".

Very odd; I've checked the source for 2.16d and it works exactly the
same way as GremNOS, i.e. the "current session" info passed to commands
like "record" is the "most recently escaped from" session, which is
initially set to the main command session.  If the "most most recently
escaped from" session ends, the marker is reset to nothing, and remains
that way until next time you use F10.

However, as discussed, there's no reason why it should remain that way!

>         - i think the last-session marker resetting to the main command
>         screen session, and/or the main command screen session being one
>         of the options selectable with the "s(ession)" command - "s0" ?
>         "main command screen" or "net> prompt" ?, and capable of having
>         the last session marker associated with it, would be the most
>         flexible & useful.

I definitely think that resetting the last-session marker to the command
screen, rather than nothing, when the current last-session ends would be
a Good Thing.  I'm still thinking about whether making "s 0" return you
to the main command screen would be useful (if you can type "s 0",
you're already there!); perhaps it might be useful in scripts in a way I
haven't thought of yet.

>         (but, not knowing how much work it might involve, i can't say it
>         is a particularly high priority - after all, it hasn't proved to
>         be an essential fix in over two and a half decades :-) )

True, until I wanted you to record the POP3 trace stuff and you
couldn't...

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer