Re: Turning Gnus groups into real objects

[Lars Ingebrigtsen]

Eric Abrahamsen <address@hidden> writes:

> 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.

Yes, there's a bunch of out-of-tree backends out there.

> But maintaining two pairs of interface functions would be a nightmare,
> and likely negate most of the potential benefit of using generic
> functions.

I don't see why.  You'd just leave the gnus-int-* functions alone (but
deprecated) and carry on.

> 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)
>       ...))))

Oh, I see -- want the objects to be in Gnus, not just in the backends?
Yes, then I can see how that'd be more complicated to have the two
interfaces.

But I don't there's that much value in carrying around the backend
objects inside Gnus.  I think the current list-based server objects
could still live on the Gnus side.  And I think moving away from those
would lead to, basically, breaking half the Gnus users' .gnus.el files.

> I'd aim at a few general principles:
>
> 1. Move more code into the methods, in particular the base methods.

I'm not sure what you mean here...

> 2. Where possible, give servers their own process buffer (for if we ever
>    want to make Gnus threaded).

Don't they have that already?

> 3. Let all servers keep track of a list of "their" groups.

Keep track in what way?

> 4. Wherever possible, pass servers as arguments instead of guessing them
>    from the environment.

Sure.

> 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'm not sure what you refer to -- there's a bunch of code that allows
you to refer to servers based on the name as well as the actual backend
definition (that has grown for historical reasons)...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no