@MSGID: 2:6078/1 65508f7c
@REPLY: 2:6078/80 65508428
@CHRS: CP866 2
@TZUTC: 0200
@TID: hpt/w32-mvcdll 1.4.0-sta 16-02-06

Приветики, Cheslav!


Писал как-то Cheslav Osanadze к Dmitriy Romanov  примерно 12 Ноя 23  в 09:52
А я смотрю и фигею.

 CO>>>>>  Не видны они в редакторе не по отсутствию базы, а потому что
 CO>>>>> Голдед понимает этот параметр и не отображает эту базу. А сама
 CO>>>>> база имеет право быть, для возможности рескана линкам.
 DR>>>> Тогда проще настроить представление в голдеде, чтобы он просто
 DR>>>> не показывал то, что не нужно.
 CO>>>  Совсем не проще, чем вставить ключ -0 в неинтересное или убрать
 CO>>> его - из интересного и получить эху уже "отресканеную", т.к. база
 CO>>> то накоплена! :)
 DR>> Так это оно и есть. Включаешь только вариант показывать или не
 DR>> показывать в голдеде. База все равно хранится локально.

 CO>  Надо Голдеду рассказать про все эхи. Или как он будет разбирать, что
 CO> показать, а что нет? Там двумя символами на эху - не обойтись.
 CO>  Не хочется в Голдеде прописывать эхи, там тоссер уже не сможет
 CO> удалять/добавлять эхи.
 Вариант вот прямо сходу - для голдеда формировать отдельный список
эх скриптом из конфига тоссера. Но это вот как я бы
 сделал вотпрямщас. Наверняка если порыться, то там где-нибудь
что-нибудь для этого есть.


 DR>>>> Вот интересно, не реализовали ли
 DR>>>> где-нибудь транзитный рескан?
 CO>>>  Мне кажется, это можно намутить с помощью трекера.
 DR>> Боюсь это будет сильное колдунство. Надо чтобы свалившееся по
 DR>> транзитному рескану проверилось на дупы, и так как это рескан - то
 DR>> дупы должны быть отправлены только запросившему линку, а остальное
 DR>> должно быть обработано штатным образом, так как с линка-хранилища
 DR>> могут прийти письма не только по рескану, а еще и обычные.

 CO>  На вскидку - трекер только для пересылки транзитного запроса, который
 CO> принят в нетмыле, а уж с пришедшей базой пусть тоссер разбирается.
 CO>  Только... Совсем далеко запросить - не получится, наверное.
 Вот это самое сложное и есть, что сделать с пришедшей базой. Пока
только как вариант - желающему самому настраивать
 линк с поинтом-хранилищем и запрашивать оттуда. Либо по ручному
запросу выгрузка базы по эхе целиком, пусть сам
разбирается дальше.


 DR>> то поясню
 DR>> примерно. У меня есть специальный технический поинт 1.128, который в
 DR>> свое время работал как nntp-гейт. Потом с переездом я его работу
 DR>> остановил, но почта на него валится. Но это мелочи. База от него есть,
 DR>> и вся почта на него лежит. При поднятии разве что придется растоссить
 DR>> 30 гигов почты. По идее оно задумано не только как nntp-гейт, но и как
 DR>> хранилище архивов всех эх, чтобы на ноде не держать. Сей
 DR>> поинт автоматически подписывается на все эхи при создании - он вписан
 DR>> в шаблон автосоздания. Осталось дело за малым - предусмотреть
 DR>> возможность выгрузки из него запросившему линку.
 CO>  Мне кажется, на один "прыжок", оно должно работать. Тонкости уже в
 CO> процессе реализовать.
 CO>  Правда. как реализовать повторный рескан, уже после получения базы от
 CO> "архивного пойнта", я не придумал с лёту.:)
 Предполагается, что повторного рескана не будет. Локальная база
отсутствует полностью. Надо "помнить", что это был
 именно запрос рескана, и пришедшие письма слить не в дупы, а на
голову запросившему линку. Вот где-то на этом этапе и
 возникает самая сложность. А так то мне не трудно подключить всех
линков с ноды в конфиг архива, чтобы можно было
писать туда напрямую. Кстати, тоже как вариант.

      Hа сем разрешите письмо закончить.   Elec (RA2FDR)
--- NoSFeRaTU`s GoldED+/W32-MINGW 1.1.5-b20090603
 * Origin: В свинарнике не стыдно быть свиньей (2:6078/1)
SEEN-BY: 478/0 37 5005/49 5015/46 255 5019/40
5020/715 848 1042 4441 8080
SEEN-BY: 5020/12000 5030/49 1081 5058/104 6035/3
6078/0 1 2 3 47 60 80
@PATH: 6078/1 80 5020/1042 4441