Re: OffGnus

Re: OffGnus

[St. Suika Fenderson Roberts]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Rich Pieri <rich.pieri@prescienttech.com> writes:
>> LMI> No -- nnagent will always download all the headers.  It's only the
>> LMI> article bodies that are interesting to decide whether should be
>> LMI> fetched or not.
>> 
>> You misunderstand.  If I score an article low based on how many lines it
>> contains, it will not appear in the summary buffer where I want it to

> I must be misunderstanding something basic here, because you and I
> seem to be saying the same things here.  Only we're disagreeing.  :-)

> 2) Uses a scoring scheme to say what articles to download, and
>    also downloads articles that have been manually marked for
>    download, no matter what their scores are.

The way I'm seeing this whole arguement is this:

Lars is saying that headers will be `scored' to determine if the article
will be auto-downloaded.

Rich is fearing that this means that the scoring to determine whether to
show an article in the summary will be affected by lowering the
auto-download score for articles that are too big, which could push
articles scores low enough that they are not displayed.

As long as the display scores affect the auto-download scores, and not
vice-versa, I don't see any problem with using scoring to determine
auto-downloadablity.  If the auto-download scores affect the summary
display scores one could well end up with problems . . .

hope this helps,
	Suika
--
		wrobert2@mailhost.tcs.tulane.edu
      No matter how big a pair she's got, an enemy is an enemy.
      							--Moroboshi Ataru

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "SSFR" == St Suika Fenderson Roberts
>>>>> <wrobert2@mailhost.tcs.tulane.edu> writes:

SSFR> Rich is fearing that this means that the scoring to determine
SSFR> whether to show an article in the summary will be affected by
SSFR> lowering the auto-download score for articles that are too big,
SSFR> which could push articles scores low enough that they are not
SSFR> displayed.

Exactly.  I would like to see a second set of auto-download score files,
or something.  I am seeing something like this occouring in automatic
retrieval mode:

1.  Retrieve headers for the group from the server.
2.  Run these headers through the normal scoring process.
3.  Run these headers through a special set of auto-retrieve scores.
4.  Retrieve any articles that have >=0 scores.

Later, when the summary buffer is generated and the group is being read,
the auto-retrieve scores are ignored,

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuedtZ6VRH7BJMxHAQFInAP+I3ST3us/Rw2Vbla3grjDYVZLqFI9SMnC
Nog3OM5NUDwWPgy8Gfaf9OoQkb/61LYeBLwnpEyozM4soxTzrHDJJ0NXDQohAfbh
40xG6v08bM24fAGPtQjb29zoqfK4UPr2ZdTkSEAlDHCApqe3yNMKZSb16WblIsxZ
9HDRDGlioZk=
=siqM
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | When not in use, Happy Fun Ball
Prescient Technologies, Inc.              | should be returned to its special
A Stone & Webster Company                 | container and kept under
I speak for myself, not PTI or SWEC       | refrigeration.

OffGnus

[Lars Magne Ingebrigtsen]

It was suggested that it might be nice to be able to read news
"offline" with Gnus.  Currently, we three ways of reading news (and
mail) on a machine that's not really connected to the net:

1)  inn+suck (or whatever) and pop.  That is, we set things up
properly and let other programs deal with how to shuffle things
to/from the net.

2)  Using the cache.  This doesn't really work as well as it should,
since Gnus insists on trying to connect to the real server even most
of the articles are present in the cache.

3)  nnsoup.  Using soup is quite fiddly, but it basically seems to
work.  Shuffling the packages from/to the net is a pain, though.

Yesterday I had someone give me a demonstration of (Free) Agent.
While I didn't really like it very much, it seems to have a quite nice
approach to "offline"-ness.  It basically fetches all the headers to
the groups, and then you can manually say which article bodies to
fetch, or have the newsreader fetch things automatically.  Not very
advanced, but it seems to be quite nice.

So -- I propose writing a new backend for Gnus provide similar
functionality.  I don't know what to call it (nnoff?  nnoffline?  I
don't really like the word "offline".), but I'm sure that someone will
come up with a good name.  Right?

Describing what the backend should do seems kinda difficult, so
perhaps I should just write it instead.  :-)  It has to know how to
get news from the "real" server, and it has to store headers and
article bodies locally.  (I originally thought I could just use the
cache for this, but it would complicate things.)  Like the mail
backends, it has to be able to expire old news, and it has to be able
to heed Supersedes/Cancel (if wanted).  I'm wondering whether to use
some database thingie, or to just use active/nov things, like in the
cache.  There has to be a special "outbox" where outgoing news is
stored, and people should be able to edit/not send things in the
outbox.  (Perhaps nndraft should make a comeback?)  

To control which articles to automatically fetch from which groups
(using scoring, etc) we can use group/topic parameters.  

Uhm, ah...  Even though this won't be trivial, I don't think it will
be all that much work.  And I think it will be useful.  As more and
more people move to modem-connected Linux/Windoze boxes, "offline"
newsreaders get more useful, not less...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> 1)  inn+suck (or whatever) and pop.  That is, we set things up
LMI> properly and let other programs deal with how to shuffle things
LMI> to/from the net.

This also does not necessarilly work all that well on non-Unix machines
(Windows 95 and NT).

LMI> 2)  Using the cache.  This doesn't really work as well as it should,
LMI> since Gnus insists on trying to connect to the real server even most
LMI> of the articles are present in the cache.

Right now there are two or three mail queueing schemes out there.  The
one I am currently using, a wrapper for smtpmail, was recently posted to
gnu.emacs.sources.  It would be *really* nice to have something like
this for news.

LMI> 3)  nnsoup.  Using soup is quite fiddly, but it basically seems to
LMI> work.

Like #1, yes on Unix.  I have been demonstrably unsuccessful in getting
nnsoup to work on my Windows 95 machine, most probably due to the poor
handling of I/O streams in the console mode API.

[...]

LMI> So -- I propose writing a new backend for Gnus provide similar
LMI> functionality.  I don't know what to call it (nnoff?  nnoffline?  I
LMI> don't really like the word "offline".), but I'm sure that someone will
LMI> come up with a good name.  Right?

nntpol, since this will basically be nntp with off-line extensions.

I suggest a merger between nntp.el and nnml.el.  This "new" backend will
use nntp's code to slurp news from the server and nnml's code to store
and read it locally.  For outgoing mail we need smtpmail.el (which is
distributed with GNU Emacs, now) and smtpmail_delay (or smtpmailq, as I
prefer), which is a simpler setup than feedmail.  For outgoing news,
message-post-method (or whatever) should be pointed at a queueing
function, and then a "foo-post-queued-news-now" function (which can be
added to whatever desired exit hooks or invoked manually) which
processes the queue.

Here is a slightly modified version of smtpmailq.el:

; $Id: smtpmail_delay.el,v 1.3 1997/01/11 15:13:17 gko Exp $
; Georges KO gko@mail.net.tw

(require 'smtpmail)
(require 'mailalias)
(require 'time-stamp)

(defvar smtpmail-delay-popout-dir "~/Mail/queue/")
(defvar smtpmail-delay-popout-index-file "index")

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defvar smtpmail-delay-popout-index (concat smtpmail-delay-popout-dir
					    smtpmail-delay-popout-index-file))

(defun smtpmail-queue-it ()
  "Hacked version of smtpmail-send-it: stores the message in a file in 
smtpmail-delay-popout-dir and updates smtpmail-delay-popout-index."
  (require 'mail-utils)
  (let ((errbuf (if mail-interactive
		    (generate-new-buffer " smtpmail errors")
		  0))
	(tembuf (generate-new-buffer " smtpmail temp"))
	(case-fold-search nil)
	resend-to-addresses
	delimline
	(mailbuf (current-buffer)))
    (unwind-protect
	(save-excursion
	  (set-buffer tembuf)
	  (erase-buffer)
	  (insert-buffer-substring mailbuf)
	  (goto-char (point-max))
	  ;; require one newline at the end.
	  (or (= (preceding-char) ?\n)
	      (insert ?\n))
	  ;; Change header-delimiter to be what sendmail expects.
	  (goto-char (point-min))
	  (re-search-forward
	    (concat "^" (regexp-quote mail-header-separator) "\n"))
	  (replace-match "\n")
	  (backward-char 1)
	  (setq delimline (point-marker))
;;	  (sendmail-synch-aliases)
	  (if mail-aliases
	      (expand-mail-aliases (point-min) delimline))
	  (goto-char (point-min))
	  ;; ignore any blank lines in the header
	  (while (and (re-search-forward "\n\n\n*" delimline t)
		      (< (point) delimline))
	    (replace-match "\n"))
	  (let ((case-fold-search t))
	    (goto-char (point-min))
	    (goto-char (point-min))
	    (while (re-search-forward "^Resent-to:" delimline t)
	      (setq resend-to-addresses
		    (save-restriction
		      (narrow-to-region (point)
					(save-excursion
					  (end-of-line)
					  (point)))
		      (append (mail-parse-comma-list)
			      resend-to-addresses))))
	    ;; Don't send out a blank subject line
	    (goto-char (point-min))
	    (if (re-search-forward "^Subject:[ \t]*\n" delimline t)
		(replace-match ""))
	    ;; Put the "From:" field in unless for some odd reason
	    ;; they put one in themselves.
	    (goto-char (point-min))
	    (if (not (re-search-forward "^From:" delimline t))
		(let* ((login user-mail-address)
		       (fullname (user-full-name)))
		  (cond ((eq mail-from-style 'angles)
			 (insert "From: " fullname)
			 (let ((fullname-start (+ (point-min) 6))
			       (fullname-end (point-marker)))
			   (goto-char fullname-start)
			   ;; Look for a character that cannot appear unquoted
			   ;; according to RFC 822.
			   (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]"
						  fullname-end 1)
			       (progn
				 ;; Quote fullname, escaping specials.
				 (goto-char fullname-start)
				 (insert "\"")
				 (while (re-search-forward "[\"\\]"
							   fullname-end 1)
				   (replace-match "\\\\\\&" t))
				 (insert "\""))))
			 (insert " <" login ">\n"))
			((eq mail-from-style 'parens)
			 (insert "From: " login " (")
			 (let ((fullname-start (point)))
			   (insert fullname)
			   (let ((fullname-end (point-marker)))
			     (goto-char fullname-start)
			     ;; RFC 822 says \ and nonmatching parentheses
			     ;; must be escaped in comments.
			     ;; Escape every instance of ()\ ...
			     (while (re-search-forward "[()\\]" fullname-end 1)
			       (replace-match "\\\\\\&" t))
			     ;; ... then undo escaping of matching parentheses,
			     ;; including matching nested parentheses.
			     (goto-char fullname-start)
			     (while (re-search-forward 
				     "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)"
				     fullname-end 1)
			       (replace-match "\\1(\\3)" t)
			       (goto-char fullname-start))))
			 (insert ")\n"))
			((null mail-from-style)
			 (insert "From: " login "\n")))))
	    ;; Insert an extra newline if we need it to work around
	    ;; Sun's bug that swallows newlines.
	    (goto-char (1+ delimline))
	    (if (eval mail-mailer-swallows-blank-line)
		(newline))
	    ;; Find and handle any FCC fields.
	    (goto-char (point-min))
	    (if (re-search-forward "^FCC:" delimline t)
		(mail-do-fcc delimline))
	    (if mail-interactive
		(save-excursion
		  (set-buffer errbuf)
		  (erase-buffer))))
	  ;;
	  ;;
	  ;;
	  (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*"))
	  (setq smtpmail-recipient-address-list
		(or resend-to-addresses
		    (smtpmail-deduce-address-list tembuf (point-min) delimline)))
	  (kill-buffer smtpmail-address-buffer)

	  (smtpmail-do-bcc delimline)
	  
	  ;;;;;;;;;;; Above is the same as smtpmail-send-it ;;;;;;;;;;;;;;;;

	  ;;; Put everything in queue
	  (let* ((file-data (concat 
			      smtpmail-delay-popout-dir
			      (time-stamp-strftime 
			       "%02y%02m%02d-%02H%02M%02S")))
		(file-elisp (concat file-data ".el"))
		(buffer-data (create-file-buffer file-data))
		(buffer-elisp (create-file-buffer file-elisp)))
	    (save-excursion
	      (set-buffer buffer-data)
	      (erase-buffer)
	      (insert-buffer tembuf)
	      (write-file file-data)
	      (set-buffer buffer-elisp)
	      (erase-buffer)
	      (insert (concat
		       "(setq smtpmail-recipient-address-list '"
		       (prin1-to-string smtpmail-recipient-address-list)
		       ")\n"))	    	    
	      (write-file file-elisp)
	      (set-buffer (generate-new-buffer "*popout*"))
	      (insert (concat file-data "\n"))
	      (append-to-file (point-min) 
			      (point-max) 
			      smtpmail-delay-popout-index)
	      ))))))

(defun smtpmail-send-queued-mail-now ()
  "Sends messages queued by smtpmail-queue-it."
  (interactive)
  ;;; Get index, take first file, send message, take second file, etc...
  (let ((buffer-index (find-file-noselect smtpmail-delay-popout-index))
	(file-msg "")
	(tembuf nil))
    (save-excursion
      (set-buffer buffer-index)
      (beginning-of-buffer)
      (while (not (eobp))
	(setq file-msg (buffer-substring (point) (save-excursion
						   (end-of-line)
						   (point))))
	(load file-msg)
	(setq tembuf (find-file-noselect file-msg))
	(if (not (null smtpmail-recipient-address-list))
	    (if (not (smtpmail-via-smtp smtpmail-recipient-address-list 
					tembuf))
		(error "Sending failed; SMTP protocol error"))
	  (error "Sending failed; no recipients"))  
	(delete-file file-msg)
	(delete-file (concat file-msg ".el"))
	(kill-buffer tembuf)
	(kill-line 1))      
      (set-buffer buffer-index)
      (save-buffer smtpmail-delay-popout-index)
      )))

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuOMmJ6VRH7BJMxHAQEt6QP/SIU6b5bxNiUQlExiLNJhcNQjl/tc2oPy
fxLuFuPqmbxBJ5NB2tIPCaNTjKwLP63XSdzxbwxPyInObgom9ydZ5h6ufu9yHWCl
a8VIowD+g6aUeR4Ie17ULYHOqtTD1NPOFl+gwIRS1mAoxWsM9NtOg2yIa2VFpXOp
/oahHisP5mw=
=+InJ
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Do not taunt Happy Fun Ball.
Prescient Technologies, Inc.              | 
A Stone & Webster Company                 | 
I speak for myself, not PTI or SWEC       | 

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "RP" == Rich Pieri <rich.pieri@prescienttech.com> writes:

RP> I suggest a merger between nntp.el and nnml.el.  This "new" backend
RP> will use nntp's code to slurp news from the server and nnml's code
RP> to store and read it locally.

Some more thoughts on what to implement...

Score rules should be applied before any articles are retrieved (which
is pretty much how things are now).  At this point there are three use
modes to handle:

* off-line: download all articles with a score greater than or equal to
  some customizable value, defaulting to 0.

* on-line: works exactly like nntp does now, excepting that any read
  articles that are not already in the local spool are added when they
  are retrieved (similar to passive caching).

* interactive off-line: user explicitly marks the articles to retrieve,
  which are then stored in the local spool.  Summary buffers should have
  the ability to be "narrowed" to display just articles that are in the
  local spool area.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuPGjp6VRH7BJMxHAQFN5QP9HbRSnJOEcgO2P8+kGHO0j4OujsHdeZLP
0d1Az5QHgZ5fB1ndN5bExFcs5pmQgPxTYEPwp+W2pt8XU8IiZSCKPOUx0HS2anKi
wkmbRCDiftf6q3xP7j3/xeg51LKRa9w9RXlQMyJQNV5kzK9xuc7fLty0xHN04+R3
r4diqXY8HW0=
=2ZSA
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Do not taunt Happy Fun Ball.
Prescient Technologies, Inc.              | 
A Stone & Webster Company                 | 
I speak for myself, not PTI or SWEC       | 

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> Some more thoughts on what to implement...
> 
> Score rules should be applied before any articles are retrieved (which
> is pretty much how things are now).  At this point there are three use
> modes to handle:
> 
> * off-line: download all articles with a score greater than or equal to
>   some customizable value, defaulting to 0.
> 
> * on-line: works exactly like nntp does now, excepting that any read
>   articles that are not already in the local spool are added when they
>   are retrieved (similar to passive caching).
> 
> * interactive off-line: user explicitly marks the articles to retrieve,
>   which are then stored in the local spool.  Summary buffers should have
>   the ability to be "narrowed" to display just articles that are in the
>   local spool area.

Yes.  There'll be a number of ways for users to specify what they
want -- primarily based on scores, explicit marks and group/topic
parameters. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "RP" == Rich Pieri <rich.pieri@prescienttech.com> writes:

RP> * off-line: download all articles with a score greater than or equal to
RP>   some customizable value, defaulting to 0.

One more thing for this: number of lines should be another determiner
apart from score, so an article should be downloaded if score > minimum
and #lines < maximum.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuPHjp6VRH7BJMxHAQGs4QP9HYfxwIarivzYJIYqUxspRT8PABm679Vh
yzFxdCegp/6HZufb6qDdSte1mpd1AhsvIFkPbjl60Jev+fZ1Mlz1kkty12RxXzI/
UouCJv1EoHpeh3hOZJRFavpHLH+OQIupqG0Ye/03tIDCBdtchCR2aRhoEVuprHKy
wt6uzpMqA9E=
=dIpK
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Do not taunt Happy Fun Ball.
Prescient Technologies, Inc.              | 
A Stone & Webster Company                 | 
I speak for myself, not PTI or SWEC       | 

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> One more thing for this: number of lines should be another determiner
> apart from score, so an article should be downloaded if score > minimum
> and #lines < maximum.

You can just lower the score of all articles with a length greater
than some number.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> Rich Pieri <rich.pieri@prescienttech.com> writes:
>> One more thing for this: number of lines should be another determiner
>> apart from score, so an article should be downloaded if score > minimum
>> and #lines < maximum.

LMI> You can just lower the score of all articles with a length greater
LMI> than some number.

Length and score checking should be independant.  Long articles should
not have their scores lowered just because they are longer than a given
number of lines.  I want these articles to appear in the summary buffer
where they should be; I just do not want to download them unless I
explicitly do so.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuTbx56VRH7BJMxHAQGvPAQAleb3wAvoHjnkP/4HkO0ThFwo6Ck/djXK
l0Srr8tX26tl3IQBrzZdodp2w6qnaKbrwNTgOLsKWCGytXB8adHMwyz7eW7G846M
vx+fT+FxZTMI6tRPylVku+8w3UfV2EqGyT6/hLgnT4B4GQLzM53eIa43nHDOt8bq
tACt8G0XArs=
=cVKq
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Happy Fun Ball contains a liquid
Prescient Technologies, Inc.              | core, which, if exposed due to
A Stone & Webster Company                 | rupture, should not be touched,
I speak for myself, not PTI or SWEC       | inhaled, or looked at.

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> Length and score checking should be independant.  Long articles should
> not have their scores lowered just because they are longer than a given
> number of lines.  I want these articles to appear in the summary buffer
> where they should be; I just do not want to download them unless I
> explicitly do so.

Yes -- the scoring I'm talking about won't be applied to the groups
when you read them; just when you fetch them.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> Yes -- the scoring I'm talking about won't be applied to the groups
LMI> when you read them; just when you fetch them.

If the article is scored low, it will not appear in the summary buffer.
I will not be able to tag it for downloading either later in off-line
mode or "now" in on-line mode.  This is exactly what I do not want to
happen.  This is why for a separate lines threshold for automatic
downloading.

Scoring should be run on the group both at download time and read time.
I may not read all of a given group "now", but the score data for it
will have changed.  If I go back to that group those changes should be
reflected in what I see in the summary buffer.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuVHh56VRH7BJMxHAQGDFgP+IhhBo9Lxg5wVTTpoxG0iOv5zXkn134rn
+YRhEH773yqeVBoQ7y0+8lz2sbbCLdj8c5QiKHtWgkY5H1N0PvdRMgxxq0icC9Ij
p6A/u+qTC44o7BaGQKo0kJtwQ/XFEVEiKIHuxAkZkYPCYYyexgyZW5GDw+1+eCmG
w8CwFVLxhRA=
=FCzh
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | If Happy Fun Ball begins to smoke,
Prescient Technologies, Inc.              | get away immediately. Seek shelter
A Stone & Webster Company                 | and cover head.
I speak for myself, not PTI or SWEC       | 

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> If the article is scored low, it will not appear in the summary buffer.
> I will not be able to tag it for downloading either later in off-line
> mode or "now" in on-line mode.  This is exactly what I do not want to
> happen.  This is why for a separate lines threshold for automatic
> downloading.

No -- nnagent will always download all the headers.  It's only the
article bodies that are interesting to decide whether should be
fetched or not.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> No -- nnagent will always download all the headers.  It's only the
LMI> article bodies that are interesting to decide whether should be
LMI> fetched or not.

You misunderstand.  If I score an article low based on how many lines it
contains, it will not appear in the summary buffer where I want it to
appear: where it would appear had I not scored it based on lines.  I
want that summary line to be there.  I just do not want to have that
article automatically downloaded; I want the option of seeing it right
there and being able to tag it for download at read time.

This is why I want a separate lines threshold for "bulk" downloads.  I
made extensive use of a similar feature in Agent -- yes, I purchased and
used the full version before Emacs was stable on Win32.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuYudp6VRH7BJMxHAQGr2AP9FJ3dY46yZ1h5nR6FA113UeDS6a8U43Ax
RFEHgp6+d/81kSNw6PMVU3jj+DzCiEfB90dkX/eEOyp6RWUunuUMutZYtznRXe1J
5SztMZr9FhzxTgHk8YohkHhLXDS+mLhhEUmRUorU1e0filyZs+qzW/buRNKZhnp+
zwh2BXm4CDI=
=dEAa
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Do not taunt Happy Fun Ball.
Prescient Technologies, Inc.              | 
A Stone & Webster Company                 | 
I speak for myself, not PTI or SWEC       | 

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> LMI> No -- nnagent will always download all the headers.  It's only the
> LMI> article bodies that are interesting to decide whether should be
> LMI> fetched or not.
> 
> You misunderstand.  If I score an article low based on how many lines it
> contains, it will not appear in the summary buffer where I want it to
> appear: where it would appear had I not scored it based on lines.  I
> want that summary line to be there.  I just do not want to have that
> article automatically downloaded; I want the option of seeing it right
> there and being able to tag it for download at read time.

I must be misunderstanding something basic here, because you and I
seem to be saying the same things here.  Only we're disagreeing.  :-)

So, here's what I see happening:

When downloading groups, nnagent:

1) Always downloads all headers, and
2) Uses a scoring scheme to say what articles to download, and
   also downloads articles that have been manually marked for
   download, no matter what their scores are.

The scoring scheme can be any normal Gnus scoring scheme -- "From",
"Lines", "Subject", whatever.  All headers to all articles (downloaded
or not) will of course appear in the summary buffer.  Unless you want
them to.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[David Moore]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> 1) Always downloads all headers, and
> 2) Uses a scoring scheme to say what articles to download, and
>    also downloads articles that have been manually marked for
>    download, no matter what their scores are.
> 
> The scoring scheme can be any normal Gnus scoring scheme -- "From",
> "Lines", "Subject", whatever.  All headers to all articles (downloaded
> or not) will of course appear in the summary buffer.  Unless you want
> them to.

	I think you are agreeing as long as the prefetch is based on a
new score field like (prefetch -100) get everything with score -100 or
better.  If it's based on a notion of mark or expunge, then you don't
want a line's field in there.  You might also want conditionalized
scoring, either being more or less liberal in the prefetch than you do
for your normal scoring.


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

Re: OffGnus

[Lars Magne Ingebrigtsen]

David Moore <dmoore@UCSD.EDU> writes:

> 	I think you are agreeing as long as the prefetch is based on a
> new score field like (prefetch -100) get everything with score -100 or
> better. 

Yes, something like that or even a separate fetch score group
parameter.  Like:

(agent-score ("from" ("Lars" -1000000)) ("lines" (1000 -1000 nil >)))

Other group parameters would be `agent-fetch' which can be a list of
`all', `scored', uhm...

Relying on group parameters is kinda nice, because you just add the
things to the topic parameters, and you get nice, consistant rules.
For instance, the "global" fetch parameters would just be the
parameters of the root topic.  (Ain't y'all glad that I insisted that
there had to be a root topic?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> 1) Always downloads all headers, and
LMI> 2) Uses a scoring scheme to say what articles to download, and
LMI>    also downloads articles that have been manually marked for
LMI>    download, no matter what their scores are.

Up to this point we agree.  What I want is an additional check on the
length of the article, after the first round of scoring is performed.
If the article is bigger than some length, regardless of score, it
should not be automatically downloaded.

Just for example, a modified chunk of my summary buffer:

   :  258|Rich Pieri           Re: OffGnus
   : 1284| Lars Magne Ingebrigt 

I do not want "your" 1284-line article scored low; but I neither do I
want to automatically download it, because I am on a 14.4Kb modem link.
I do want it to appear in its "proper" place in the summary buffer.  If
I try to select that article I should be prompted to download it if I am
in on-line mode, or marked for downloading later in off-line mode.

With just normal scoring, I would either have to download the article
(assuming automatic downloading is turned on) or score it low so that it
is not automatically downloaded (thus pushing it out of thread order).

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMueZ4p6VRH7BJMxHAQHg0AP9HQVdGZkTm4aJYLy/hmkEI1KIMg4Gsnqr
hiptHQgAf9lL4d9BS/TqfCmE7FbKlI5+skQMxr3870HaBT6bXAinKuLVghjTyzRb
hhwpvXQw/CZtHVb3qlwETjYpX5NW5zTJCSr2ZywGhtab2PPnC1hknP7glsM9a6L/
jmTpuepChZA=
=qgZh
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | When not in use, Happy Fun Ball
Prescient Technologies, Inc.              | should be returned to its special
A Stone & Webster Company                 | container and kept under
I speak for myself, not PTI or SWEC       | refrigeration.

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> Up to this point we agree.  What I want is an additional check on the
> length of the article, after the first round of scoring is performed.
> If the article is bigger than some length, regardless of score, it
> should not be automatically downloaded.

No, if you don't want long articles, then you just lower the score of
the long articles.

> I do not want "your" 1284-line article scored low; but I neither do I
> want to automatically download it, because I am on a 14.4Kb modem link.
> I do want it to appear in its "proper" place in the summary buffer.

The download scores are orthogonal to the display scores.  If you want
them to be.  They'll probably be most useful accumulative, so that you
basically add a download score file to the normal score files when
downloading. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> The download scores are orthogonal to the display scores.  If you
LMI> want them to be.

Yes, I want them to be.  That is exactly what I want them to be (or at
least have the option for them to be).

[...]

> No, cmsgs are posted to the "control" group.

LMI> The Newsgroups header of cancel messages are normally identical to
LMI> the Newsgroups header of the message to be canceled.  This is done
LMI> to facilitate distributing the relevant cancel messages to the
LMI> sites that need it.

If the Newsgroup header of a cancel message is identical to the
Newsgroup header of the message being canceled, the cancel message will
never show up in 'control', will not be processed, and the message to be
canceled will never be canceled.

I think....

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMui/zZ6VRH7BJMxHAQFJgQQAybElh4RVGkvlrwlzOlv997+79LVv6Ovo
m3mG68vaEc99w5844T3Fetc1Vyu6HCPYTVRa353m27C9ALbhy8+oBobg2RPEjDcW
pSUHc+qQH7lU0kLzVY29hfSPK7aaCaxbrY5k9a1YfItXqp9tW6nkSVyHB5uvvPaw
QA71OKqoV2A=
=Bz6z
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Caution: Happy Fun Ball may
Prescient Technologies, Inc.              | suddenly accelerate to dangerous
A Stone & Webster Company                 | speeds.
I speak for myself, not PTI or SWEC       | 

Re: OffGnus

[Per Abrahamsen]

Rich Pieri <rich.pieri@PrescientTech.com> writes:

> If the Newsgroup header of a cancel message is identical to the
> Newsgroup header of the message being canceled, the cancel message will
> never show up in 'control', will not be processed, and the message to be
> canceled will never be canceled.

Wrong.

Re: OffGnus

[dave edmondson]

: RP> * off-line: download all articles with a score greater than or equal to
: RP>   some customizable value, defaulting to 0.
: 
: One more thing for this: number of lines should be another determiner
: apart from score, so an article should be downloaded if score > minimum
: and #lines < maximum.

rather than distinguish between score and #lines, couldn't your
scoring take the number of lines into account ?

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> LMI> 3)  nnsoup.  Using soup is quite fiddly, but it basically seems to
> LMI> work.
> 
> Like #1, yes on Unix.  I have been demonstrably unsuccessful in getting
> nnsoup to work on my Windows 95 machine, most probably due to the poor
> handling of I/O streams in the console mode API.

I got it to work pretty well last Xmas when I was stuck on a Windos 95
box...  It's too fiddly, though.  Not sexy at all.

> LMI> So -- I propose writing a new backend for Gnus provide similar
> LMI> functionality.  I don't know what to call it (nnoff?  nnoffline?  I
> LMI> don't really like the word "offline".), but I'm sure that someone will
> LMI> come up with a good name.  Right?
> 
> nntpol, since this will basically be nntp with off-line extensions.

No; it will handle both mail and news, and won't be restricted to nntp
at all.  For instance, some may dial up their ISP, NFS mount the news
spool and tell the offline backend to fetch all the news from that,
and then hang up and read the mail from the offline backend.  So the
offline backend (when fetching news) will simply do that by accessing
some other Gnus backend.

nnagent?  

> I suggest a merger between nntp.el and nnml.el.  This "new" backend will
> use nntp's code to slurp news from the server and nnml's code to store
> and read it locally.  For outgoing mail we need smtpmail.el (which is
> distributed with GNU Emacs, now) and smtpmail_delay (or smtpmailq, as I
> prefer), which is a simpler setup than feedmail.  For outgoing news,
> message-post-method (or whatever) should be pointed at a queueing
> function, and then a "foo-post-queued-news-now" function (which can be
> added to whatever desired exit hooks or invoked manually) which
> processes the queue.

I think all outgoing news and mail should be stored in a special
folder, and that the offline backend should run the queue when the
connection has come up.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> I think all outgoing news and mail should be stored in a special
LMI> folder, and that the offline backend should run the queue when the
LMI> connection has come up.  

How does it "know" that the connection has come up?  And then, how does
it know that the connection that has come up will allow sending out the
queued mail and news?  Trying to open a connection to a news server that
cannot be reached can cause Emacs to freeze for several minutes (I have
experienced this phenomenon on several occasions).  Some kind of user
intervention is probably the best way to do it.

I think I like "nnagent" as a name.

And I still think that the backend should borrow heavilly from nnml.
The news spool format is the most effective method of storing news -- it
is somewhat wasteful in disk space (depends on how big your inodes or
clusters are), but is faster for reading and requires much less memory
to process.  nnml duplicates this format, so you might as well use that
code for something.

This leaves nnagent with the task of playing traffic cop between nntp --
which talks to the news server -- and nnml -- which talks to the local
spool.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuTgD56VRH7BJMxHAQFNFgQArT2Tv3TK5MT0CYlLtVkANtY2eaDBXTRX
Yd/KdB18Eq+eb1FdNWQ5DkVTqxZETVJ0uRzYqHTfvaG7OV0VXKjKzhrSTtvDJjfP
mmXyhOwKQPMBckOvRaxSf1DFU2ctMlhGLr60hKAII/TYwPySaOV5/qXa9vw4oNmT
MUfscUQYQSg=
=BIfq
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Warning: pregnant women, the
Prescient Technologies, Inc.              | elderly, and children under 10
A Stone & Webster Company                 | should avoid prolonged exposure to
I speak for myself, not PTI or SWEC       | Happy Fun Ball.

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> How does it "know" that the connection has come up? 

The user says so.  This is what Agent does -- the user taps `C-o' to
let Agent know that it's online.

> I think I like "nnagent" as a name.

And they probably won't sue me.  :-)

> And I still think that the backend should borrow heavilly from nnml.
> The news spool format is the most effective method of storing news -- it
> is somewhat wasteful in disk space (depends on how big your inodes or
> clusters are), but is faster for reading and requires much less memory
> to process.  nnml duplicates this format, so you might as well use that
> code for something.

Yes -- I'll probably take much code from nnml and gnus-cache, but
since the requirements are somewhat different (for instance, it should
be possible to heed Supersedes), the code probably can't be shared
directly.  To make it efficient, it's a possibility that I'll have to
use some sort of external (or internal) data base system or
something...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

>> How does it "know" that the connection has come up? 
LMI> The user says so.  This is what Agent does -- the user taps `C-o'
LMI> to let Agent know that it's online.

How about `M-o' instead?  `C-o' is already bound in the summary buffer.

>> I think I like "nnagent" as a name.
LMI> And they probably won't sue me.  :-)

We can hope :).

[...]

LMI> Yes -- I'll probably take much code from nnml and gnus-cache, but
LMI> since the requirements are somewhat different (for instance, it should
LMI> be possible to heed Supersedes), the code probably can't be shared
LMI> directly.

Won't Supersedes be superseded on the news server?  In essence, a
majority of the nntp code in agent will be in duplicating what is on the
server.

Or do you mean superseding in the local spool area?

LMI> To make it efficient, it's a possibility that I'll have to use some
LMI> sort of external (or internal) data base system or something...

When an article is "posted" it gets put into the local spool where it
should go, and the message ID, group, and article number are stored in
the .../out.going/<target-server> database.  When a spool out connection
to a particular server goes live, nnagent can run through that server's
outgoing database on a line-by-line basis and upload the corresponding
articles.  Just like a real news server (and Agent, for that matter).

As for the equivalent of a history database, it has already been
partially implemented in nnml in the .nnmail-cache mechanism.

Wow... Gnus, the news reader that is also a news server.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuYxLZ6VRH7BJMxHAQFpbwQAm+ELAkgUkk537czdK6nLHOUlPCYKIXU0
4dZTtVGyobn0HldocwrxYr2AXyz0VpPh31SPvQ28KiEe3Vae9H2XBwe3ZK/PFBst
/GbdoDTnMFfTWGTnc/eIkmuTq3WqrL9uqJJsSBAxje5P7YA1wn8Cld+e3JHOiBoj
Wh8TTCVE2fE=
=aOfy
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | If Happy Fun Ball begins to smoke,
Prescient Technologies, Inc.              | get away immediately. Seek shelter
A Stone & Webster Company                 | and cover head.
I speak for myself, not PTI or SWEC       | 

Re: OffGnus

[Justin Sheehy]

>>>>> "Rich" == Rich Pieri <rich.pieri@PrescientTech.com> writes:

Rich> Won't Supersedes be superseded on the news server?  In essence,
Rich> a majority of the nntp code in agent will be in duplicating what
Rich> is on the server.

If you download an article which is later Superceded on the server,
agent has to know how to deal with Supercedes: headers locally.

-Justin

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "JS" == Justin Sheehy <dworkin@ccs.neu.edu> writes:

JS> If you download an article which is later Superceded on the server,
JS> agent has to know how to deal with Supercedes: headers locally.

Right... so just like a regular news server, agent needs to keep a
history database of message IDs with corresponding group and article
number information.  That is already halfway done with the nnmail-cache
code.

The history database and the outgoing message queue database [will]
store the same information, so agent might as well use the same code to
maintain both.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMuZ4Zp6VRH7BJMxHAQHTvAP+Jmt1okorucSAqxHMCNV8y0hTeoTnhQSh
KlKTZWDs96aLQlJxNSi+OS1dT0Evrd0CPX7YW65ClQ6KRGueQAZSS5QYHTsetd+9
+4XQpYZ7D164Pq8NO1dN5udUtS3f5y1rJqeREMAY3sdrG3WKKFpjVxBvX+hlp6DT
fk+0fIc1DZQ=
=cdAo
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Ingredients of Happy Fun Ball
Prescient Technologies, Inc.              | include an unknown glowing
A Stone & Webster Company                 | substance which fell to Earth,
I speak for myself, not PTI or SWEC       | presumably from outer space.

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> How about `M-o' instead?  `C-o' is already bound in the summary buffer.

It probably won't be any `o'-ish key in Gnus.

> As for the equivalent of a history database, it has already been
> partially implemented in nnml in the .nnmail-cache mechanism.

Yes, but it isn't fast.  When a cancel message comes in, it should be
possible to efficiently remove the canceled article, and perhaps some
db thing would be nice.

Perhaps it won't be necessary, though, since the cancel messages are
usually posted to the same group(s) that the articles appeared in, so
finding the relevant articles can be done by just looking at the
.overview files, really.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Rich Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> Yes, but it isn't fast.  When a cancel message comes in, it should
LMI> be possible to efficiently remove the canceled article, and perhaps
LMI> some db thing would be nice.

The history db should contain the article's message ID, which "folder"
it is being stored in (relative to the top of the local spool), and the
article number.  But that is beside the point.  cmsgs contain the
message ID of the article to cancel and the group(s) the article was
originally posted to.  Building the path(s) based on the group
information is trivial.  That leaves you to grep through each local
group's .overview file for the message ID string which will in turn
provide the article number.  From there you can do whatever you want...
like delete the messages file and update the .overview database.

Just don't use filesystem links like a Unix news server; we do not have
them on Win32.

Hmmm... so the history database is redundant for this.  The only reason
a real news server keeps it is to serve a purpose identical to
nnmail-cache.

LMI> Perhaps it won't be necessary, though, since the cancel messages are
LMI> usually posted to the same group(s) that the articles appeared in,

No, cmsgs are posted to the "control" group.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBMueb5J6VRH7BJMxHAQHfrAQAiMYVYSMLGdrZArehqzop1GzLEmioavbs
qIomgKQCWKo3/F4wNb3n1AJ2G+b9lfuXJQTBFSSaJzK8IDFXiFesrW+A4V14LqGm
1zxG3pE2MCGBQRYO5KkArS8PCkDnebMLOzuCWFWRKyM6+PlrHO3Co0mZkk29KW4g
/WIzY/HBsws=
=Ras6
-----END PGP SIGNATURE-----
-- 
Rich Pieri <rich.pieri@prescienttech.com> | Happy Fun Ball contains a liquid
Prescient Technologies, Inc.              | core, which, if exposed due to
A Stone & Webster Company                 | rupture, should not be touched,
I speak for myself, not PTI or SWEC       | inhaled, or looked at.

Re: OffGnus

[Lars Magne Ingebrigtsen]

Rich Pieri <rich.pieri@prescienttech.com> writes:

> LMI> Perhaps it won't be necessary, though, since the cancel messages are
> LMI> usually posted to the same group(s) that the articles appeared in,
> 
> No, cmsgs are posted to the "control" group.

The Newsgroups header of cancel messages are normally identical to the
Newsgroups header of the message to be canceled.  This is done to
facilitate distributing the relevant cancel messages to the sites that
need it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> So -- I propose writing a new backend for Gnus provide similar
  Lars> functionality.  I don't know what to call it (nnoff?
  Lars> nnoffline?  I don't really like the word "offline".), but I'm
  Lars> sure that someone will come up with a good name.  Right?

I'd like it to deal with "B m" and "B c", too, though.  WIBNI I could
slurp my mail, read it offline, do some refoldering, ticking and
stuff, then `upload' that information to the server again?

I currently use the mirror program to do that.  It works, but it's got
to compare huge directories and it's got to transfer rather large
.overview files.

kai
-- 
I like both kinds of music.

Re: OffGnus

[Patrick Audley]

Kai Grossjohann <grossjohann@charly.informatik.uni-dortmund.de> writes:

> I'd like it to deal with "B m" and "B c", too, though.  WIBNI I could
> slurp my mail, read it offline, do some refoldering, ticking and
> stuff, then `upload' that information to the server again?
> 
> I currently use the mirror program to do that.  It works, but it's got
> to compare huge directories and it's got to transfer rather large
> ..overview files.

	That would save me a lot of time ;)  I use mirror right now so
that I can read mail at work and at home.

-- 
... Your reality check just bounced.
/*--------------<a href=http://www.pobox.com/blackcat">-----------.
| The Crystal Wind is The Storm,      Patrick Audley              |
|    The Storm is The Data,     ______/\/\/\/\/\/\/\_______       |
|      The Data is Life.        InterNet: paudley@pobox.com       |
`---[Anime]-[Trance]-[C++]-[linux]-[Solaris]---------------------*/

Re: OffGnus

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de> writes:

> I'd like it to deal with "B m" and "B c", too, though.  WIBNI I could
> slurp my mail, read it offline, do some refoldering, ticking and
> stuff, then `upload' that information to the server again?

That would be outside the scope of an offline newsreader, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: OffGnus

[Darren/Torin/Who Ever...]

-----BEGIN PGP SIGNED MESSAGE-----

Lars Magne Ingebrigtsen, in an immanent manifestation of deity, wrote:
>Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de> writes:
>> I'd like it to deal with "B m" and "B c", too, though.  WIBNI I could
>> slurp my mail, read it offline, do some refoldering, ticking and
>> stuff, then `upload' that information to the server again?
>
>That would be outside the scope of an offline newsreader, I think.

Hmm.  But that's exactly what I need Gnus to do.  I have XEmacs at work
and can bring in mail on a floppy.  It'd be nice if I could take mail
in; read some; take the control file back home; have it update the
.newsrc.eld in Gnus and the next day generate a new control files and
articles I've neither read not taken in to work...

Hmmm.  I haven't done more than tweaking in lisp for years.  If I get
the time I might try this though.

Darren
- -- 
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMundvY4wrq++1Ls5AQFqCAP/Xm+9UfH6z5bPVzXnIv3DLoaVI5pTuJKS
gqgqw76Z+9+QLqn36vhYqxSzO3VM9bOMEaScETx54w/RMr53YRQ/GHMVmvXUgerg
frR3aHV6kvu4gVm9iJOUs53HWVBORC0NqRuACtbNaHHdpkgs5D49y8wvFExiImqF
/3FEQys9ZYI=
=sB/N
-----END PGP SIGNATURE-----