q0.12: agent comments

q0.12: agent comments

[Felix Lee]

any chance the agent will become unified with the cache?  I
find it kinda odd to have both.

for foreign servers, agent wasn't storing an active file
until I put them in gnus-secondary-select-methods.  is this
normal?  is this ok?

how do I tell agent I only want ten groups fetched every
time I "J s"?  my newsrc has a couple hundred groups that
I'm vaguely interested in but don't read often.

it's kinda annoying that agent doesn't store articles in a
group until after it fetches them all.  if it ever gets
interrupted in middle of fetching, it has to start all over.

making it async would be good.  but in the meantime,
howabout a batch-mode fetch?
--

Re: q0.12: agent comments

[Lars Magne Ingebrigtsen]

Felix Lee <flee@teleport.com> writes:

> any chance the agent will become unified with the cache?  I
> find it kinda odd to have both.

They are orthogonal.

> for foreign servers, agent wasn't storing an active file
> until I put them in gnus-secondary-select-methods.  is this
> normal?  is this ok?

It's normal, but I don't know whether it's ok or not.

> how do I tell agent I only want ten groups fetched every
> time I "J s"?  my newsrc has a couple hundred groups that
> I'm vaguely interested in but don't read often.

Fiddle with the categories.

> it's kinda annoying that agent doesn't store articles in a
> group until after it fetches them all.  if it ever gets
> interrupted in middle of fetching, it has to start all over.

Yup.  I've now put this on the todo list.

> making it async would be good.  but in the meantime,
> howabout a batch-mode fetch?

I've now added a `gnus-agent-batch-fetch' command.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: q0.12: agent comments

[Felix Lee]

> > how do I tell agent I only want ten groups fetched every
> > time I "J s"?  my newsrc has a couple hundred groups that
> > I'm vaguely interested in but don't read often.
> Fiddle with the categories.

as far as I can tell, fiddling with categories only affects
article fetching, not overview-fetching, right?  I really
don't need to spend an hour waiting for overview data from
300 groups I rarely read.

> > any chance the agent will become unified with the cache?  I
> > find it kinda odd to have both.
> They are orthogonal.

yeah, but they do some of the same things.

I should have said instead.. any chance the agent will gain
most of the functionality of the cache?  I mean like, right
now I have agent, asynch, backlog, and cache enabled, as
parts of an ad-hoc plan to minimize waiting for slow ppp
traffic.  and so I can end up with 2 or more copies of the
same article stored in various disk and memory locations.

really, all I need is agent, once it gets async data fetch
and semi-intelligent expire.  (eg, for ! marks, instead of
putting the article into the cache, mark it as not to be
expired.)
--

Re: q0.12: agent comments

[Lars Magne Ingebrigtsen]

Felix Lee <flee@teleport.com> writes:

> > > how do I tell agent I only want ten groups fetched every
> > > time I "J s"?  my newsrc has a couple hundred groups that
> > > I'm vaguely interested in but don't read often.
> > Fiddle with the categories.
> 
> as far as I can tell, fiddling with categories only affects
> article fetching, not overview-fetching, right?

Yup.

> I really don't need to spend an hour waiting for overview data from
> 300 groups I rarely read.

Then just unsubscribe the groups you don't read very often.

> I should have said instead.. any chance the agent will gain
> most of the functionality of the cache?  I mean like, right
> now I have agent, asynch, backlog, and cache enabled, as
> parts of an ad-hoc plan to minimize waiting for slow ppp
> traffic.  and so I can end up with 2 or more copies of the
> same article stored in various disk and memory locations.

If you switch all four on, you'll usually have five copies of each
article stored somewhere.  :-)  (Three of them inside Emacs, but
still...) 

> really, all I need is agent, once it gets async data fetch
> and semi-intelligent expire.  (eg, for ! marks, instead of
> putting the article into the cache, mark it as not to be
> expired.)

Why not just use `*' to make the article persistent instead?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: q0.12: agent comments

[Felix Lee]

> > and semi-intelligent expire.  (eg, for ! marks, instead of
> > putting the article into the cache, mark it as not to be
> Why not just use `*' to make the article persistent instead?

I do that sometimes, but *ed articles tend to go away once
they're marked as read, right?  which is perfectly
acceptable behavior.  (and simpler than trying to type M-*
to uncache articles.)

unrelated musing..

lately I've been reading work-related news by gnus'ing
remotely on an rlogin over 28k ppp.  despite the sluggish
display and the mediocre interactive response, this is
surprisingly much more _usable_ than gnus'ing locally with
nntp over 28k ppp.  mostly because I don't have these random
delays waiting for data to arrive.

there's something wrong here.  maybe I'll stop running gnus
locally.  (except then I'll need some other way of saving
the collected genius of Archimedes Plutonium, not to mention
all those Xxxciting! Hot! Babes! that want to meet me
personally.)

or maybe I need a different backend that talks to an
intermediate reader agent that reduces the data transfer
substantially..  (compression is probably a good first try;
news data (like overview) tends to compress very well.)
--

Re: q0.12: agent comments

[Andy Eskilsson]

/ Felix Lee <flee@teleport.com> wrote:
| or maybe I need a different backend that talks to an
| intermediate reader agent that reduces the data transfer
| substantially..  (compression is probably a good first try;
| news data (like overview) tends to compress very well.)

nnextern.. ;-)

	/a

gnus over compressed nntp

[Felix Lee]

this may improve life on the end of a ppp link..

after spending way too long writing a streaming gzip
(zlib-1.0.4 is a little quirky), I've settled on using
'ssh -C' instead.

basic idea is, instead of gnus connecting directly to
newshost:nntp, you have it run
    ssh -C proxyhost 'tcp newshost nntp'

or maybe
    ssh proxyhost 'tcp newshost nntp | zstream' | zstream -d

which would be worth it if zstream did better compression
than ssh -C.  (it does, but not really enough.)

though with zstream, you can use rsh if you don't have ssh.
but if you're hanging off ppp, rsh probably doesn't work for
you..  telnet is possible, but painful, and I don't really
want to do it.

anyway... 'ssh -C' is easy.  something like this should
work:

(setq gnus-select-method
      '(nntp "proxyhost"
	     (nntp-open-network-stream nntp-open-rlogin)
	     (nntp-rlogin-program "ssh")
	     (nntp-rlogin-parameters '("-x" "-C" "telnet" "-8" "newshost" "nntp"))))

now to figure out if the compression really helps or not...
--

Re: gnus over compressed nntp

[Samuel Tardieu]

Note that you can also use port redirections over SSH and ask that
port 1190 on your local machine (for example) be redirected on port
119 on another machine (from the remote side of the SSH link).

For example, what I do on my home machine is: (my office machine is
esmeralda.enst.fr and my news server is news.enst.fr)

  ssh -C -L 119:news.enst.fr:119 esmeralda.enst.fr

(as root, since I want to use a privileged port and have no news
server running locally)

Then I start Gnus with localhost as nntpserver. When I'm done, I just
exit from esmeralda.enst.fr.

  Sam
-- 
Samuel Tardieu -- sam@inf.enst.fr