Re: Turning Gnus groups into real objects

[Eric Abrahamsen]

Lars Ingebrigtsen <address@hidden> writes:

> Eric Abrahamsen <address@hidden> writes:
>
>> My original long-term plan was to replace the nnoo machinery with Emacs'
>> built-in object stuff: defvoo would become object slots, and deffoo
>> would become generic functions. Would this be a bad idea for the same
>> reason? That would also be a bummer, but at the same time save me a lot
>> of work :)
>
> The reason the voo stuff is like it is is for backwards-compatibility
> with out-of-tree backends.  If we want to keep that, then rewriting to
> use a proper object system would require two pairs of interface
> functions.

I guess it seems unlikely that a lot of external code is messing with
server internals, but I suppose it's possible that some Gnus astronauts
have written entire new backends for themselves. But maintaining two
pairs of interface functions would be a nightmare, and likely negate
most of the potential benefit of using generic functions.

> But I think rewriting that stuff is a more self-contained operation
> because the nn* interface at least is defined as an interface (which the
> group/info structures are not).  So I think that's a much better thing
> to be rewritten.
>
> I.e., first define what the interface should be, then rewrite the
> backends, one by one, to use that new and better interface.  People who
> have customisations to the code will find that their customisations
> don't work in the new versions, but that's OK, I think.

Okay, cool. Just for clarity, we'd end up with something looking like:

(defclass gnus-server ()
  ((address :type string)
  ...))

(defclass gnus-nnimap (gnus-server)
  ((capabilities
    :type string)
   (newlinep
    :type boolean)
   ...))

(cl-defmethod gnus-request-list ((server gnus-nnimap))
  (when (nnimap-change-group nil server)
    (with-current-buffer nntp-server-buffer
      (erase-buffer)
      (let ((groups
             (with-current-buffer (nnimap-buffer)
               (nnimap-get-groups)))
            sequences responses)
        ...))))

I'd aim at a few general principles:

1. Move more code into the methods, in particular the base methods.
2. Where possible, give servers their own process buffer (for if we ever
   want to make Gnus threaded).
3. Let all servers keep track of a list of "their" groups.
4. Wherever possible, pass servers as arguments instead of guessing them
   from the environment.
5. Keep a "real" list of servers, equivalent to `(cons gnus-select-method
   (append gnus-secondary-select-methods gnus-server-alist))', so we
   don't have to keep looking for them.

I can try to start off with the absolute smallest change possible, but
something tells me it won't work to switch the backends over gradually,
ie to maintain a hybrid system for a while. It will probably need to
happen all in one go (though again, I can minimize changes in the
beginning).

Anyway, all this is still quite a ways down the road. Thanks for looking
at this.

Eric