Q: Extending nntp (for nndb)

Q: Extending nntp (for nndb)

[Kai Grossjohann]

Hi there,

I'm trying to extend nntp so that it deals with the things that make
sense for `private' nndb groups, like `B c' and `B m' and expiry and
stuff.  I admit that I've never really looked into the source before,
and I'm not sure what I should do.

There are several issues:
    - What exactly are the backend functions supposed to do?
    - How do I deal with all the variables and group parameters?

Ad 1:  Backend functions.

The documentation for, say, nnchoke-request-accept-article, says:

,-----
| `(nnchoke-request-accept-article GROUP &optional LAST)'
|      This function takes the current buffer and inserts it into
|      GROUP.  If LAST in `nil', that means that there will be more
|      calls to this function in short order.
| 
|      There should be no data returned.
`-----

Note the last sentence.  From debugging nnml, however, it seems that
this function should return ("<group name>" <article number>).  What's
the story?  How do the return values interact with this strange buffer
that's supposed to contain the results, if any?

Are there other things that the docs don't mention but I should know?
Remember that this was my first cut at trying anything.


Ad 2: Variables, group parameters.

I created a file nndb.el with a lot of defalias statements, for all
the functions that already exist in nntp.el.  I figured that this way,
I would only need to write the missing functions.

However, I would like nndb to use port 9000 by default, changeable via
parameters, as usual.  How would I go about this?

Further, when in a function, how do I find out the values of all the
parameters (host, port, whatever), considering that the currenly valid
value may come from a group parameter, may come from the server
definition, or may come from one of the variables which change the
defaults.  And this isn't considering the environment variables, even.

Maybe this was a completely stupid approach of doing it?  Should I've
copied nntp.el then change every occurrence of "nntp" to "nndb", then
change the defaults at will?  Should I've extended nntp.el instead to
recognize the new servers?  Is ELisp object oriented and supports
inheritance but I don't know it?

Thanks a lot for you kind help for a novice Gnus programmer,
        kai
--
There ain't no cure for the summer time blues.

Re: Q: Extending nntp (for nndb)

[Lars Magne Ingebrigtsen]

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

> The documentation for, say, nnchoke-request-accept-article, says:
> 
> ,-----
> | `(nnchoke-request-accept-article GROUP &optional LAST)'
> |      This function takes the current buffer and inserts it into
> |      GROUP.  If LAST in `nil', that means that there will be more
> |      calls to this function in short order.
> | 
> |      There should be no data returned.
> `-----
> 
> Note the last sentence. 

By "data", the manual means "data in the nntpd buffer".  I forgot to
mention the function return value.

> Further, when in a function, how do I find out the values of all the
> parameters (host, port, whatever), considering that the currenly valid
> value may come from a group parameter, may come from the server
> definition, or may come from one of the variables which change the
> defaults.  And this isn't considering the environment variables, even.

The `*-open-server' function sets all variables in the backend.  So
all the other functions can assume that they are working on variables
local to the current virtual server.  

> Maybe this was a completely stupid approach of doing it?  Should I've
> copied nntp.el then change every occurrence of "nntp" to "nndb", then
> change the defaults at will?  

Yes, probably.  nndb and nntp are sufficiently different that there
probably should be a new nndb.el file.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Q: Extending nntp (for nndb)

[Kai Grossjohann]

>>>>> On 27 Mar 1996 04:49:37 +0000, Lars Magne Ingebrigtsen
>>>>> <larsi@ifi.uio.no> said:

  Lars> By "data", the manual means "data in the nntpd buffer".  I
  Lars> forgot to mention the function return value.

I see.  By  reading a bit more, I found that there is in fact one
function where the return value is mentioned: a list of article
numbers.  Can I assume that this is the same for other functions?

  Lars> The `*-open-server' function sets all variables in the
  Lars> backend.  So all the other functions can assume that they are
  Lars> working on variables local to the current virtual server.

So if I were to add to the nntp.el file a new function, said function
could just use the variable nntp-address to get the name of the nntp
server?

  Kai> Maybe this was a completely stupid approach of doing it?
  Kai> Should I've copied nntp.el then change every occurrence of
  Kai> "nntp" to "nndb", then change the defaults at will?

  Lars> Yes, probably.  nndb and nntp are sufficiently different that
  Lars> there probably should be a new nndb.el file.

Really?  Please note that nndb offers a superset of the nntp protocol.
Therefore, the nntp subset would have to be maintained twice if the
two were completely independent nndb.el and nntp.el files.  Well, I
don't like this idea, but you're the guru, so I'll comply.

Why is ELisp not object-oriented?

        kai
--
There ain't no cure for the summer time blues.

Re: Q: Extending nntp (for nndb)

[Per Abrahamsen]

>>>>> "KG" == Kai Grossjohann <grossjoh@charly.informatik.uni-dortmund.de> writes:

KG> Why is ELisp not object-oriented?

You can write OO code in any language.  I think nn* packages would
benefit much from being specified in a way that used and allowed
inheritance.  When I (attempted to) write nnsoup I constantly wanted
to be able to say "this is just like nnml, except...".  There is a lot
of duplication between the backends which could be avoided. 

nndir is actually written as a kind of subclass of nnmh, so you might
want to look at that.

Re: Q: Extending nntp (for nndb)

[Lars Magne Ingebrigtsen]

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

>   Lars> By "data", the manual means "data in the nntpd buffer".  I
>   Lars> forgot to mention the function return value.
> 
> I see.  By  reading a bit more, I found that there is in fact one
> function where the return value is mentioned: a list of article
> numbers.  Can I assume that this is the same for other functions?

Nope.  Most of the functions do not return any useful function values,
but the ones that do return useful things all return in different
formats.  For instance, `*-retrieve-headers' return `nov' or
`headers'.  This should be documented better.

> So if I were to add to the nntp.el file a new function, said function
> could just use the variable nntp-address to get the name of the nntp
> server?

Yes.  If you look over the code, most of the functions start with 
`(nntp-possibly-change-server group server)', which deal with all that
gruft.  After calling that function, all variables should be ok.

>   Lars> Yes, probably.  nndb and nntp are sufficiently different that
>   Lars> there probably should be a new nndb.el file.
> 
> Really?  Please note that nndb offers a superset of the nntp protocol.
> Therefore, the nntp subset would have to be maintained twice if the
> two were completely independent nndb.el and nntp.el files.  Well, I
> don't like this idea, but you're the guru, so I'll comply.

Well, I didn't mean that you should rewrite all functions.  Here's
a typical nndir function.  (nndir is a wrapper around nnmh in much the
same way nnbd would be a wrapper around nntp.)

(defun nndir-request-newgroups (date &optional server)
  (nndir-execute-nnmh-command
   `(nnmh-request-newgroups ,date ,server)))

`nndir-execute-nnmh-command' binds the relevant nntp variables and
evals that form.

The main reason that I'd rather not see functions like
`nntp-request-accept-article' is that nntp servers are read-only, and
the presence of such a function would make Gnus believe that Gnus
could delete articles from the nntp backend.  Which isn't really true.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."