Re: where to add code to make it possible to "encode" the mail folder

Re: where to add code to make it possible to "encode" the mail folder

[Kai Großjohann]

I think that mail-sources is the wrong place to add this stuff: Gnus
reads from a mail source and writes to a group.  From your wording,
you want to support encryption and compression when storing messages.

I think you want to have a look at the various backends nnfolder, nnml
and so on.  I think you don't want to replicate the code, so you'd
need to change all the backends to use a common interface for writing
files (or for naming files?).

Hm.  Yes, that would make sense: you could frob the backends so that
they write the file foo.gz rather than foo, and then you could let
auto-compression-mode take over.

kai
-- 
~/.signature: No such file or directory

Re: where to add code to make it possible to "encode" the mail folder

[Kai Großjohann]

Jonas Steverud <d4jonas@dtek.chalmers.se> writes:

> When I thought later of it after I mailed my suggestion I thought one
> should be able to configure this on server basis.
> I.e. gnus-secondary-select-methods.

You can make a backend (server) parameter of it, then you can frob it
on a per-server basis.

> Depending on the exakt usage of mail-sources maybe it still should be
> possible to use it - but I know too little of the inner working of
> Gnus to be able to make any decisions now.

Hm.

> > From your wording,
> > you want to support encryption and compression when storing messages.
> 
> I also want to be able to have the infolder encrypted/compressed.

What is the `infolder'?  /var/spool/mail/jrl?  Note that this file is
written to by some other program, not Gnus.  Therefore, changing Gnus
does not change what's in the file.

But mail-sources would be the right place to change things if you want
to be able to read from an encrypted/compressed /var/spool/mail/jrl
file. 

> > I think you want to have a look at the various backends nnfolder, nnml
> > and so on.
> 
> I thought so too but is there any documentation of how they work,
> i.e. which function that get called by which function, or can
> someone supply me with such a thing? Or do I have to revert to
> reverse engineering?

Well, you might wish to search the Gnus info file for `nnchoke'.  You
will then find a programmer's manual showing you all the API functions
that a backend must support as well as the optional functions.  It
will also show you how to write a backend.

As to how the individual backends work, I'm afraid there is not much
documentation.  I hope you will be able to figure it out yourself.

One other pointer is nnoo.el which allows you to derive backends from
other backends in an object oriented fashion (inheritance).  It works
kinda strangely for someone who is used to OOP, but after a while you
get used to it.

kai
-- 
OOA: object oriented analysis.  OOD: object oriented design.
OOP: object oriented programming.  OOPS: object oriented errors.