Getting into GNUS development

Getting into GNUS development

[David Abrahams]

Hi,

I've been having some persistent reliability problems with GNUs,
several of which have been reported here, but which nobody seems to be
addressing.

After having searched hard for alternatives, I find I'm addicted to
the kind of interface possibilities GNUs provides and I seriously
doubt I'm going to be happy with anything else.  So, I'm willing to
apply some of my own open-source elbow grease to try to fix up some of
these problems, and if I can get that far, perhaps even to add some
usability enhancements and features.

The architecture of GNUs, however, is almost completely opaque to me.
Beyond the basics like the fact that messages are collected by
backends, I don't understand how it's organized, what the flow of
control/data are, what the *real* significance of and difference among
the various caches (e.g.  agent) are, etc.  I've looked through the
docs I could find, even printed the GNUs manual (sometime back in a
previous version) but was unable to get a picture of what's going on.
Is there any better way to get started with GNUs development other
than the "use the source, Luke" approach?  That probably makes the
barrier too high for me to get my toes wet, if you'll pardon the mixed
metaphor.

Thanks in advance,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: Getting into GNUS development

[Lars Magne Ingebrigtsen]

David Abrahams <dave@boost-consulting.com> writes:

> The architecture of GNUs, however, is almost completely opaque to me.

Architecture?  What architecture?  :-)

Uhm...  Gnus is a blob that talks to the world (mostly) via nn*
backends.  Then there's a mid-layer consisting of the Agent and the
cache.  gnus-int.el has all the functions for controlling that flow. 

> Is there any better way to get started with GNUs development other
> than the "use the source, Luke" approach?  That probably makes the
> barrier too high for me to get my toes wet, if you'll pardon the mixed
> metaphor.

Gnus has the advantage over other, er, big programs that it's in
Emacs.  The most likely approach to take if command `x' doesn't work
is to find its source and `M-x edebug-defun' that function and see
what goes on.

Gnus is big, but it isn't very complex.  Things normally just layer
down a few times until you get to where things really happens.  Using
etags, the Emacs help system, some debugging statements and the
source, it's possible to dig down to just where the problem is...

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

Re: Getting into GNUS development

[Kai Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Gnus is big, but it isn't very complex.  Things normally just layer
> down a few times until you get to where things really happens.  Using
> etags, the Emacs help system, some debugging statements and the
> source, it's possible to dig down to just where the problem is...

nnoo alone is sufficient to make it *quite* complex, IMHO.  I don't
grok that.

Another thing that seems complex to me is the data storage that Gnus
uses.  I didn't try very hard, but the way Gnus remembers which
messages I've seen and which newsgroups and all this stuff is a
mystery to me.

Kai