Re: Documentation of nnoo.el

[Eric Abrahamsen]

Lars Ingebrigtsen <address@hidden> writes:

> Eric Abrahamsen <address@hidden> writes:
>
>> Does this mean you'd rather not go all the way with EIEIO? Maybe just
>> vectors or something?
>
> EIEIO would be fine by me...
>
>> Well that's the real crux, isn't it :) I'm happy to try banging together
>> a preliminary example of how it might look. I don't think rewriting the
>> backends would be as much work as adjusting pretty much everything else
>> to use the new code.
>
> Well, every reference to a server variable in the backends would need to
> be rewritten as an object access instead, so there would be quite a lot
> of churn on the backend side, too.  I kinda thing there wouldn't be as
> much on the Gnus side...

Sure -- I guess it's bound to be a whole lot of tweaking no matter what.

>>>> 1. First, only make backends into classes. This would give us the chance
>>>>    to do away with the select-method/secondary-select-method
>>>>    distinction, and just have a list of defined servers.
>>>
>>> I think that's a totally orthogonal issue.  We could do that now, but
>>> it'd break the current naming scheme for the groups in Gnus.
>>
>> It is orthogonal, but on the other hand it would take extra effort to
>> preserve. Do you mean the "nnml+ServerName:GroupName" scheme? I don't
>> quite see how doing away with the primary/secondary distinction would
>> affect that...
>
> Groups from primary servers aren't prefixed, while groups from
> non-primary servers are...

Ah, right. I guess I still don't see why it would be so terrible to lose
that distinction, though...

Taking a step back, there are two general structural alterations I'd
like to suggest. The first is splitting up the .newsrc.eld file a bit:
right now it's sort of kitchen-sink, and feels fragile. If servers were
classes, we could use eieio-persistent to write the server definitions
to one file, and keep marks in a different file (written there by a
different backend). Group definitions/parameters could go in the same
file as the server definitions. This would make the server/group file
somewhat user editable, at least user readable, while the marks backend
would be hands-off. Things like the topic topology could go in a third
file.

The other proposal is the agent. I'm imagining the agent as a mix-in
class for server backends. It would have many of the same methods as the
servers, and would wait in the background until a server signaled a
denied/no-connection/I'm-broken error. The agent would then set the
server's "status" slot to closed or denied, and the agent's methods
would check for that status and take over the action. That would allow
the agent to potentially usurp any server functionality that the server
itself was unable to perform.

Lastly, there's the problem that EIEIO seems to still be in flux, and an
EIEIO version of Gnus would probably only work reliably with Emacs master.

Anyway, all this is totally pie in the sky! But worth discussing, I
think.

Eric