[leafnode-list] Re: Duplicate posting to a moderated group

["Matthias Andree" <matthias.andree@xxxxxx>]

Am 04.07.2009, 22:00 Uhr, schrieb clemens fischer
<ino-news@xxxxxxxxxxxxxxxxxxxxxxxxx>:

> On Thu-2009/07/02-08:46 Matthias Andree wrote:
>
>> Am 30.06.2009, 22:18 Uhr, schrieb clemens fischer
>>
>>> The last thing I could propose is a per-server flag "post_once"
>>> (boolean) indicating that posting should be considered successful if
>>> the server returns 2xx instead of waiting for the article to come
>>> back.
>>
>> Then we'll either need a way to configure which server to post
>> to, rather than determine this automatically, or alternatively, a
>> per-server posting queue, or a queue that logs possible nexthops and
>> marks them "done" after 1st successful try. This is somewhere between
>> INN's outgoing handling and a mail transfer agent...
>
> This sounds complicated.  What's wrong with trusting the upstream-server
> on the leafnode-users request?

It's the wrong concept, we're trying to work around issues, rather than
solving them or giving the local admin powerful tools to solve them.

> The original problem was conflicting
> settings re. moderation.  Let's say the user found both servers to be
> reliable, but one of them harasses moderators.  He could set only this
> server to "post_once = 1" in order to allow fetchnews to quit insisting
> as soon as it sees the "OK" response rather than post until it sees the
> articles MID.

It's not that one of the upstream server annoys moderators, but that
fetchnews (a) doesn't reconcile conflicts (this doesn't improve) and posts
to any of them every time it runs and that flags the group as open
posting, until the article appears. (b) We already have "post-once"
functionality for moderated groups.

In the long term, leafnode (or rather fetchnews) should cache the
individual servers' active files and merge them into its own, and perhaps
let the leafnode admin override group flags.

On short term, we should complain about group status conflicts - but such
warnings are only useful if we can tell the user details about the
conflict. Currently, we can't, as we merge the active files on the fly.

HTH

-- 
Matthias Andree
-- 
_______________________________________________
leafnode-list mailing list
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
https://www.dt.e-technik.uni-dortmund.de/mailman/listinfo/leafnode-list
http://leafnode.sourceforge.net/