= Сообщение: 4897 из 47117 ================================ RU.FIDONET.TODAY =
От : Mithgol the Webmaster 2:50/88 28 Nov 16 08:22:22
Кому : Alexandr Solov'yev 28 Nov 16 08:22:22
Тема : Подсистема редактирования и удаления ранее отосланных сообщений эх
FGHI : area://RU.FIDONET.TODAY?msgid=2:50/88+583bce93
На : area://RU.FIDONET.TODAY?msgid=2:50/88+57c47c57
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Знаю уж, Alexandr Solov'yev! 21:16 29 августа 2016 было сочинено мною:
ASy>> Более того - это уже пришло навсегда. А вот нежелательный/запрещенный
ASy>> контент из фэхи я могу, как модератор, долбануть через опцию replace,
ASy>> которую поддерживают все современные фэхопроцы. Раз - и вместо больших
ASy>> /сись/(зачеркнуто) глаз в фэхе лежит джипег с тем же именем, но с
ASy>> надписью "удалено модератором". Может, у кого отключена эта опция, он
ASy>> еще останется, но на основных хабах запрещенного контента уже не будет.
ASy>> Если что - придраться у не к чему.
MtW> Двадцатого августа (в предшествующем письме на эту тему) я упоминал уж
MtW> о том, что сами по себе достоинства файловых эхоконференций ещё
MtW> не означают того, что UUE-коды в эхах обойдутся без технической
MtW> поддержки, а означают то только, что и файловые эхоконференции
MtW> неплохо бы поддерживать.
MtW> Прибавлю ещё, что обыкновенные текстовые эхоконференции
MtW> много распространённее файловых, так что надо будет придумать
MtW> какой-нибудь обходной путь (например, обращение к гейту) в случае
MtW> отсутствие фэхи в системе. Проблема при этом, как я двадцатого августа
MtW> (в предшествующем письме на эту тему) упоминал, заключается
MtW> главным образом в том, что FTP-гейты файлэх проектировалися,
MtW> как правило, для употребления людьми, а не внутрибраузерною
MtW> автоматикою. И человек может там догадываться, что если на
MtW> ftp://fido.hubahuba.su/ нет подпапки (подкаталога), строго
MtW> соответствующего эхе XOFCHUBSLST по её имени, то можно (и даже разумно)
MtW> попробовать ftp://fido.hubahuba.su/XOFCHUBS.LST (с точкой) вместо неё
MtW> и быть уверенным в том, что это просто переназвано так. А вот скрипт
MtW> в фидобраузере, во-первых, не способен на такие догадки (сперва
MtW> придётся в нём программировать нестрогое сравнение без учёта точек
MtW> в имени), а во-вторых, не может быть уверен (поэтому могут быть ложные
MtW> срабатывания с принятием одной фэхи за другую фэху, если имена
MtW> отличаются только точками).
MtW> Также ещё хочу выразить досаду, и выражу. Как так получилось
MtW> в поступательном развитии Фидонета, что в фэхах появилась 'опция
MtW> replace' для замены файлов, но в текстовых эхах не появилось ничего
MtW> даже отдалённо подобного для исправления фидошником своих (ранее
MtW> отправленных) сообщений или для подмены их модератором?
Сейчас я понимаю, что этот взгляд на вещи был ошибочным. И сам я напрасно принял на веру, что эхи Фидонета отстают от фэх в этом отношении, и сообщество читателей Ru.Fidonet.Today напрасно не поправило меня и не ответило на этот риторический вопрос.
В действительности в Фидонете есть (или, по крайней мере, был) тот механизм, который позволяет редактировать и стирать сообщения, до этого уже разосланные по эхоконференциям.
Пособие по GoldED (файл GOLDREF.TXT) упоминает этот механизм на странице 129:
> ACUPDATE:
>
> This kludge is a feature of Squish 1.10: Message Broadcast
> Modify/Delete. Read the docs for Squish 1.10 for details.
К сожалению, в настоящее время я не располагаю документацией по Squish 1.10, к которой пособие по GoldED отсылает своего читателя; но, к счастью, по адресу https://groups.google.com/d/msg/fido.belg.backbone/smbycbvth1g/xM5kepot8bsJ нетрудно видеть развёрнутую цитату из документации о довольно близкой версии ── Squish 1.11:
> Squish v1.11 Reference Manual - Page 103
>
> Squish 1.10 introduces support for broadcast message deletion and
> modification. This feature allows users on remote systems to
> write an EchoMail message, and even after the message has been
> sent to a remote system, it allows the user to amend or delete
> the message on all of the systems which carry that conference.
>
> First, broadcast messages are currently only supported in Squish
> message areas. While the concept of broadcast messages could be
> easily applied to other area types, Squish needs to maintain a
> database of MSGID values for broadcast message processing. In
> the interests of speed, Squish currently does not maintain this
> information for *.MSG areas.
>
> Note that the broadcast feature also relies on the Squish .SQB
> file to store information on messages being tossed. The dupe
> file must also be large enough (as defined by the "Duplicates"
> keyword) to store information for all of the messages in the
> area.
>
> THE BROADCAST FEATURE ONLY WORKS ON MESSAGES THAT WERE ORIGINALLY
> TOSSED TO A SQUISH AREA BY SQUISH 1.10 OR ABOVE.
>
> The broadcast feature must be enabled on an area-by-area basis,
> using the "-u<node>" flag for each EchoArea definition.
>
> <node> specifies the address of a trusted uplink which is allowed
> to submit update/delete requests. (The actual origin of the
> update/delete message is not important. However, Squish will
> only process update/delete messages if it receives them from the
> node specified by -u.)
>
> For example, the following definition sends PVT_ECHO to both
> 249/106 and 107, but it only accepts update/delete messages that
> it receives from 249/106. Note that 249/106 is specified twice;
> it is listed once in the scan list, and it is listed once for the
> -u flag.
>
> EchoArea PVT_ECHO \path\pvt_echo -$ 1:249/106 107 -u106
>
> An automatic update/delete message has the same format as a
> normal message in an EchoMail area, except that it contains an
> "Area Control Update" kludge in the following format:
>
> ^aACUPDATE: MODIFY <addr> <serial>
> or
> ^aACUPDATE: DELETE <addr> <serial>
>
> For either format of the command, Squish will scan the area for a
> message containing a MSGID kludge of the format "MSGID: <addr>
> <serial>".
>
> When processing an ACUPDATE MODIFY, if the message containing
> that MSGID is found, it will be replaced in its entirety by the
> update message. The old message will retain its original message
> number. Note that Squish will strip the "ACUPDATE" line from the
> modified message before writing it to disk.
>
> When processing an ACUPDATE DELETE, if the message containing
> that MSGID is found, that message will be deleted. The contents
> of the ACUPDATE message are ignored.
>
> Note that all ACUPDATE processing is performed during "SQUISH
> OUT" phase. If an ACUPDATE message passes the "-u" security
> check, the ACUPDATE message (in its original form) will be
> scanned out to all of the nodes before the ACUPDATE operation
> takes place.
>
> In other words, ACUPDATE acts as a broadcast message to all nodes
> listed for an area. The modification/deletion is performed by
> each node that receives the message; the messages which are
> consequently modified are NOT transmitted to other nodes.
>
> All remote modify/delete transactions are noted in the Squish log
> file.
Это сообщение датируется 1997 годом, а документация по Голдеду ── 1999 годом; иными словами, около двадцати лет тому назад идея о необходимости редактирования (и даже удаления) ранее отосланных сообщений эхопочты проделала свой путь в умы разработчиков и нашла своё воплощение в коде Squish и свою поддержку (хотя бы на уровне признания существования) в коде GoldED.
Только ли в этих двух программах? ── нет, не только в них. Мы можем по адресу http://tinyurl.com/acupdate-ifmail убедиться в том, что DEB-пакет ifgate_2.14tx8.10-21_s390x.deb.263682 по внутреннему адресу /usr/share/doc/ifgate/changelog.gz.html (в списке изменений, на котором стоит дата 3 мая 1997 года) содержит многочисленные (не менее семи) упоминания ACUPDATE с рассказом о том, что ifmail (гейт из news в Fidonet) в те годы умел заменять интернетовский заголовок 'Supersedes' на фидонетовский кладж 'ACUPDATE: MODIFY', а заголовок 'Control: cancel' ── на кладж 'ACUPDATE: DELETE'.
Что же случилось с конца девяностых? Отчего позабыта эта технология?
Может быть, эта идея позабыта оттого, что изо всех эхопроцессоров (тоссеров) реализована она была только в одном сквишёвом?
Может быть, эта идея позабыта оттого, что реализация её оказалась слишком жёсткою: при прибытии новой версии сообщения она записывалася поверх старой (без всякой попытки сохранить историю правок), при прибытии указания об удалении сообщение просто удалялось из базы (без всякой попытки сохранить в базе и стёртое сообщение)? Такой подход, уж конечно, требовал известного уровня доверия; но в Фидонете не прижилась идея цифровой подписи (и вообще идея каких-либо цифровых свидетельств об авторстве, окромя разве что ориджина), так что в конфигурации Squish просто-напросто предлагалось особо пометить адреса тех (вероятно, наиболее доверенных) линков, от которых приход ACUPDATE-писем дозволяется.
Зададимся вопросом: а был ли возможным какой-либо другой подход к этому делу?
Да... но... если бы, позаимствовав у кладжей MSGID и REPLY их формат (кладж + идентификатор сообщения), в Squish постарались бы позаимствовать ещё и логику обращения с ними (то есть предполагали бы, что редактор почты станет, наряду с деревом откликов, строить также и дерево правок при помощи подсказок, столь же щедро оставленных эхопроцессором в базе ── впрочем, в простом случае речь идёт не о древовидной, а о не более чем линейной истории правок), то что ж было бы тогда? ── а тогда (как нетрудно догадываться) окромя той поддержки, которая в Squish была оказана, непременно понадобилась бы и поддержка во всех редакторах фидопочты, умеющих работать со сквишёвою базою фидопочты.
Одно дело ── когда при приходе сообщения с кладжем ACUPDATE из базы исчезает прежняя версия его: это можно тотчас же объяснить публике. Другое дело ── когда в базе начинает формироваться некая история правок, и видимость прежних версий колеблется между 'показывать как обычно' и 'скрывать в досягаемой истории' в зависимости от того, есть ли поддержка в редакторе фидопочты. Многие ли тогда заинтересуются фидошники этой новой возможностью? Многие ли заинтересуются ею авторы редакторов?
Я вдругорядь прихожу к своей прежней мысли о том, что подавляющее большинство фидонетовских новшеств сперва должно получать некоторую поддержку на уровне редакторов фидопочты (может быть, даже и наперегонки; лишь бы только эти гонки не происходили в режиме своего рода фидобраузерных войн с внедрением новшеств, не совместимых с новшествами соперников, причём отличающихся ради одного только отличия их, а не во имя реального улучшения дел). Реализация новшеств способна затем перемещаться на уровень эхопроцессора (тоссера), но только тогда, когда выяснится, что просмотр фидопочты вынуждает раз за разом совершать над всей базою почты определённые операции, которые куда проще и быстрее совершить (целиком или хотя бы частично) над отдельными сообщениями фидопочты по мере прихода их.
Пример этого ── дерево откликов: понятно, что редактору фидопочты куда труднее перебирать всё множество новых сообщений (в базе фидопочты) в поисках откликов, а эхопроцессору гораздо проще решать обратную задачу, то есть при приходе очередного сообщения видеть, служит ли оно откликом на одно из предшествующих, и затем оставлять для редактора готовый ответ (список откликов рядом с каждым из сообщений). Этот пример общеизвестен.
Как видно, построение истории правок ── ещё один такой пример. Эхопроцессору при приходе каждого сообщения проще смотреть, есть ли у него прежняя версия, а редактору куда труднее при просмотре каждого сообщения смотреть, было ли оно в последующем изменено (включая изменения изменений) или стёрто.
Более сложный пример ── ретроспективная (ретроактивная) замена аватар (картинок пользователей). Если у некоторого пользователя несколько аватар, и если он помечает их ключевыми словами, и если он затем решает назначить некоторому ключевому слову новую картинку, и если прежняя картинка со временем утрачена, то тогда редактору почты разумно показывать (при чтении прежних сообщений, когда они-то не были утрачены) вместо этой прежней картинки (которую показать нельзя, раз уж она утрачена) ту новую картинку, которая соответствует тому же ключевому слову. Однако сам редактор фидопочты для этого должен перелопатить всё множество новых сообщений (в базе фидопочты), тогда как эхопроцессор может поддерживать таблицу соответствий между аватарами и ключевыми словами их, обновляя таблицу по мере необходимости (то есть при приходе таких сообщений фидопочты, в которых под прежним ключевым словом стоит новая аватара).
Если мы захотим в Фидонете завести у себя хэштэги (по примеру Твиттера) или же простые теги (как в обыкновенной блогосфере), то и тогда задача поиска по тегу сложна для редактора, тогда как задача построения списка тегов (и для каждого из тегов ── списка сообщений, тегу соответствующих) проста для эхопроцессора.
И тем не менее (повторяю) первоначалом служит поддержка новой фичи в редакторе; только затем может явиться и у автора эхопроцессора готовность оказать помощь, готовность упростить всё дело.
Конечно, в строгом смысле для такого положения дел необходимо и то, чтоб в Фидо по мере появления и развития новых редакторов фидопочты (которое наблюдается) происходило также появление новых эхопроцессоров или развитие старых (с этим у нас некоторый затык: из новых эхопроцессоров налицо только jNode, да и тот, если правду сказать, недодокументирован; в прежних же эхопроцессорах, типа HPT, идёт разве что устранение багов, не более).
Хорошо ещё, что это только в строгом смысле. В практическом же смысле задача сбора данных, содержащихся в пришедшей фидопочте, может решаться не одним лишь эхопроцессором, но также и препроцессором, то есть такою программою или таким скриптом, который запускается после распаковывания так называемых бандлов (архивов пришедшей фидопочты), но перед собственно тоссингом (то есть перед раскладыванием в базе той фидопочты, которая извлечена из пакетов фидопочты, и тем более перед последующим удалением этих пакетов).
Такому препроцессору, впрочем, пришлось бы собирать собственную базу сведений, и притом (с целью поддержки этой базы в актуальном состоянии) предусмотреть, скорее всего, какую-то осмысленную реакцию на действия сисопа, который ведь способен, между прочим, не только сочинять исходящую фидопочту, но также ещё и заниматься удалением и даже редактированием любой предшествующей фидопочты.
Это драма превозмогания, но это ещё не трагедия погибели.
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Я хочу туда-а-а-а!!!! Я балдею! Какие деревья! Какие листья! (Hitana)
--- Эшелону: NAVCM Гамма Горизонт Guppy NSS rita ISSO submiss ASDIC .tc
* Origin: Я впредь наш Фидонет не бpошу, я сам себе сисоп хоpоший (2:50/88)
|
