forum.wfido.ru  

Вернуться   forum.wfido.ru > Прочие эхи > RU.FIDONET.TODAY

Ответ
 
Опции темы Опции просмотра
  #371  
Старый 09.10.2016, 11:00
Alexandr Solov'yev
Guest
 
Сообщений: n/a
По умолчанию Отображение иллюстраций из ююков и фэх в векторном гипертекстовом

Alexandr Solov\'yev написал(а) к Alexey Vissarionov в Oct 16 10:21:30 по местному времени:


Да не заглючит твой компьютер во веки веков, о Alexey!

09 Окт 16 02:38, ты писал(а) мне:

ASy>>>>>>>> счас полетит клип "лебедь белая". Весом мегабайт в 300.
AV>>>>>>> Ну и свалится этот ююк в badmail на ближайшем хабе
ASy>>>>>> Это если не порежут этот ююк на мелкие кусочки.
AV>>>>> Отстрелить многосекционный ююк еще проще.
ASy>>>> А что инициирует его отвал в беды? Если размер - то порезать я
ASy>>>> могу хоть по 64 кило. :-)
AV>>> Сам факт многосекционности.
ASy>> ХПТ такого, вроде, не умеет.
AV> Это ты его настраивать не умеешь :-)

Это у тебя туда перловки насовано.
Я же пользую натурпродукт. Без усилителей вкуса и ГМО. :-)

ASy>> Но можно и чем другим словить. Хоть трекером.
AV> Если уметь настраивать hpt - никакой трекер не нужен.

Да я уже обкурился мануалами - не умеет он анализировать потроха мессаг.

ASy>>>> Главное чтобы в раздачу это не ушло.
AV>>> Без явного разрешения сисопа грамотно настроенного хаба -
AV>>> не уйдет. А отправитель получит матерное письмо в полном
AV>>> соответствии 2.1.7 FPD.
ASy>> Если ловушка стоИт до тоссера.
AV> Оно в самом тоссере.

Покажи!

ASy>> Но как тогда понять, что этот многосекционник размером со своп
ASy>> винды, а не какой смешной поинт небольшой файл порезал на мелкие
ASy>> куски? Особенно если вливают аккуратно, а не все махом.
AV> А зачем?

Ну а зачем залили "лебедьбелую" в какащенку? В целях нагадить ессно.

AV> Многосекционный постинг - в badmail, если сисоп в течение суток не
AV> сказал пропустить - в /dev/null

По полиси развернуть полагается...

AV>>>>> А если этот кто-то еще и не умеет откладывать такие сообщения
AV>>>>> в сторону для последующего ручного разбора - этому кому-то о
AV>>>>> том, чтобы стать хабом, даже думать не следует.
ASy>>>> А нужен этот гемор? Эхи - не транспорт для файлов. (с) не
ASy>>>> помню.
AV>>> Нужен. Как минимум для соблюдения упомянутого выше 2.1.7 FPD.
AV>>> Иначе нехрен лезть в хабы.
ASy>> А не проще закрыть ююки вовсе? Как класс.
AV> А зачем? Иногда, наоборот, бывает даже полезно хранить бинарные данные
AV> как неотъемлемую часть сообщения - просто злоупотреблять этой
AV> возможностью не следует (а это уже забота модераторов).

Может сработать принцип веера. Раз в одном месте можно люлючить, то можно везде. И если в однои месте модератор за этим следит, то в другом модератор клал на это или его в живых давно нету.
А реакция наших хабов предсказуема - они разбираться не будут кто виноват. Долбанут что под руку попало.

Всего наилучшего в этом лучшем из миров!
Alexandr Solov'yev

... Не дадим занести Зеленого Змия в Красную книгу!!!
--- Oldest fimooznik 1.1.5-b20160322
Ответить с цитированием
  #372  
Старый 09.10.2016, 13:20
Alexey Vissarionov
Guest
 
Сообщений: n/a
По умолчанию Отображение иллюстраций из ююков и фэх в векторном гипертекстовом

Alexey Vissarionov написал(а) к Alexandr Solov\'yev в Oct 16 11:22:22 по местному времени:

Доброго времени суток, Alexandr!
09 Oct 2016 09:50:02, ты -> мне:

AV>>>>>> Отстрелить многосекционный ююк еще проще.
ASy>>>>> А что инициирует его отвал в беды? Если размер - то порезать я
ASy>>>>> могу хоть по 64 кило. :-)
AV>>>> Сам факт многосекционности.
ASy>>> ХПТ такого, вроде, не умеет.
AV>> Это ты его настраивать не умеешь :-)
ASy> Это у тебя туда перловки насовано.

~/fido/lib/hptfunctions.pl - это конфигурационный файл.

ASy> Я же пользую натурпродукт. Без усилителей вкуса и ГМО. :-)

Ага, вижу:

ASy> @TID: hpt/w32-mvcdll 1.4.0-sta 19-03-04

Как там эта протухшая рыба по чухонскому рецепту называется...
А! Лютефиск :-)

ASy>>> Но можно и чем другим словить. Хоть трекером.
AV>> Если уметь настраивать hpt - никакой трекер не нужен.
ASy> Да я уже обкурился мануалами - не умеет он анализировать
ASy> потроха мессаг.

Умеет.

ASy>>> Если ловушка стоИт до тоссера.
AV>> Оно в самом тоссере.
ASy> Покажи!

do { use bytes; $rc = length($text) };
if ($rc > 16777216)
{
return "Message too large - must be approved manually";
}

AV>> Многосекционный постинг - в badmail, если сисоп в течение
AV>> суток не сказал пропустить - в /dev/null
ASy> По полиси развернуть полагается...

Не развернуть, а уведомить отправителя.

ASy>>> А не проще закрыть ююки вовсе? Как класс.
AV>> А зачем? Иногда, наоборот, бывает даже полезно хранить бинарные
AV>> данные как неотъемлемую часть сообщения - просто злоупотреблять
AV>> этой возможностью не следует (а это уже забота модераторов).
ASy> Может сработать принцип веера. Раз в одном месте можно люлючить,
ASy> то можно везде.

Я правильно понимаю, что слово "можно" ты используешь в значении "есть техническая возможность"? Дык она есть всегда...

ASy> И если в однои месте модератор за этим следит, то в другом
ASy> модератор клал на это

Это его право.

ASy> А реакция наших хабов предсказуема - они разбираться не будут
ASy> кто виноват. Долбанут что под руку попало.

Это, соответственно, их право.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Политкорректная замена термина "черная дыра" - "афроотверстие"
--- /bin/vi
Ответить с цитированием
  #373  
Старый 11.10.2016, 20:41
Mithgol the Webmaster
Guest
 
Сообщений: n/a
По умолчанию Отображение иллюстраций из ююков и фэх в векторном гипертекстовом

Mithgol the Webmaster написал(а) к Alexandr Solov\'yev в Oct 16 14:47:18 по местному времени:

Так было 10:57 07 Oct 16 написано от Alexandr Solov'yev к Mithgol the Webmaster:

ASy> Экскоммуницировали сисопа хаба. С регионального уровня. За то, что его
ASy> поинт обидел SKL. Причем перекрыть сам фонтан люлюков не очень-то
ASy> и стремились. Тут важна была демонстрация силы. Факт тот, что куча
ASy> поинтов и линков остались без СМ аплинка. Не только автор пресловутого
ASy> люлюка. Был создан прецедент, позволяющий теперь удалить любой узел за
ASy> любую погрешность в работе без попыток разобраться.

MtW>> Кроме того, вроде как вспоминаю, что белая лебедь прошла в то время,
MtW>> когда ещё дискеты были в употреблении. С тех пор и хранилища
MtW>> информации стали куда пожирнее, и каналы связи стали куда пожирнее,
MtW>> так что аналогичный вред стало несколько труднее нанести, в
MtW>> особенности простым спамом, так что можно же ещё надеяться, что теперь
MtW>> пострадают виновные спамеры и более никто.

ASy> Если "лебедьбелая.мп3" весила 3-4 мегабайта (вроде бы, уже не помню), то
ASy> счас полетит клип "лебедь белая". Весом мегабайт в 300. Технология
ASy> позволит.

Благодаря твоим разъяснениям становится вполне ясно, что причина того инцидента
такова, что устранение спама (то есть коммерческой рекламы) или устранение UUE
(то есть технологии преобразования файлов в текстоподобные данные и обратно)
никак не способна с этой причиною покончить.

С немалым сожалением вижу, что вопрос жидокащенизма (и, шире, еврейский вопрос
в целом) подменяется вопросом о 'люлюках'; это, вне всякого сомнения, форма
невротического замещения, или пост-травматического триггера, или чего-то ещё
в этом же роде внерассудочного, позволяющего проигнорировать внетехнологический
расовый смысл того инцидента и прецедента.

Прошу в дальнейшем использовать какие-нибудь другие аргументы против UUE,
этот аргумент не годится.

MtW>> Во-первых, если я правильно понимаю, фрек (файловый запрос) никак
MtW>> не возможно отправить аплинку и получить от аплинка отклик без того,
MtW>> чтобы заодно не взять у него всю новую почту (и, может быть, также
MtW>> свою ему выслать), а это дольше, чем запрос к FTP.

ASy> 1. При современных скоростях это "дольше" сколько займет секунд?

Мне кажется, что здесь ранее оглашались аргументы о том, что не все сисопы
и тем более не все пойнты работают на современных скоростях, что кое у кого
фиговый 3G.

ASy> 2. Фрекать необязательно именно с аплинка.

Пожалуй, этот аргумент справедлив. Хотя он проблематичен в смысле той проблемы,
которая называется tragedy of the commons (трагедия общественных земель): если
с какого-то узла будет фрекать слишком много посторонних фидошников, которые
никто для него (даже не даунлинки), то узел может быть вовлечён в чрезмерные
издержки и в итоге закроет фрек нафиг (или ограничит даунлинками, способными
предъявить пароль).

MtW>> Формирование файлового запроса (фрека) ── простое дело, так что его
MtW>> в Голдеде можно видеть реализованным;

ASy> Именно так. Все уже готово. Пользователи голдедов смогут получить
ASy> контент. А если они его смотрят через жжжж, то это их выбор редактора.
ASy> :-)

MtW>> но речь же идёт вдобавок об отображении отклика, так что надо учить
MtW>> просмотрщик дожидаться ответа мейлера; а найдутся ли программисты,
MtW>> на это непростое дело готовые решиться?

ASy> Просмотровщику ничего не нужно ждать. Он должен знать, где лежит файл.
ASy> Сфреканый или полученный по фэхе - ему все равно.

Возможно, я недостаточно ясно выразился, но речь шла о том просмотрщике, какой
показывает пользователю сообщение фидопочты. Если в сообщении есть картинка
и если адрес картинки предполагает фрекание, то получается, что просмотрщик
должен сформировать файловый запрос (фрек), запустить мейлер и дожидаться того,
пока мейлер соединится и получит запрошенный файл. Не правда ли?

Конечно, фреканием теоретически может заранее заняться эхопроцессор (тоссер)
или препроцессор (то есть запускаемый изнутри эхопроцессора софт, который
имеет дело с распакованными пакетами фидопочты).

MtW>> Сам же я НTick не употребляю и фэх не имею, так что на опыте не мог
MtW>> испытать правоту или неправоту вышеизложенного впечатления.

ASy> Вот теперь я понял, откуда такая антипатия к фэхам.

Предполагаю, что я не единственный из числа сисопов, фэх не имеющих. Можем
для подтверждения этого обстоятельства попробовать устроить перепись.

Впрочем, ты можешь на это ответить, что можно и не иметь фэх, однако фрекнуть
файл, по фэхе прошедший.

MtW>>>> Простая пользовательская машина может любым современным
MtW>>>> браузером Интернета открывать SVG. (В роли браузера может
MtW>>>> выступать Mozilla Firefox, Google Chrome, Opera и др.)
ASy>>> Значит, без постоянного доступа в инет и стороннего ПО читать
ASy>>> такие сообщения невозможно?
MtW>> Доступа в Интернет не нужно. Браузер может открыть файл с диска с той
MtW>> же (или даже большей) лёгкостью, что и из Интернета.

ASy> А где на диске все это есть? Вот в фэхе все уже есть. Оттуда открывать -
ASy> милое дело. И опять браузер. Без него никак?

Те же самые вопросы относятся буквально к любому заююченному файлу. Где лежит
на диске заююченный файл? Может ли GoldED+ обойтись без внешних средств для его
просмотра? (Просто так получилось, что заююченные SVG можно открыть браузером.)

ASy>>> Тогда они влет попадут под 2.1.4. Уже без поправок, что голдед
ASy>>> тоже понимает UUE и подобного. Один особо умный начнет травлю,
ASy>>> другой его поддержит. А особо умных в фидо всегда хватало. :-)
ASy>>> Не во всем, но нужно делать на них поправку.
MtW>> Сложно веровать. Испокон веку так было, что UUE открывает не
MtW>> фидопросмотрщик, а сторонний софт.

ASy> Но даже голда умеет кодировку UUE превратить в читаемый обычным набором
ASy> софта файл. Который откроется без доступа в инет и прочих плясок с
ASy> бубнами.

Тогда при чём тут 2.1.4 вообще?

ASy>>>>> Значит надо ставить очередную приблуду?
MtW>>>> Я надеюсь, ты не ожидал того, что существующая приблуда
MtW>>>> (GoldED+) неожиданным и волшебным образом начнёт в своём
MtW>>>> алфавитно-цифровом окошке отображать также и растровую да
MtW>>>> векторную графику?

ASy> Нет. Но отобразит текст. Читаемый. А не крокозяберы.

Дык что ж поделать, когда это не текст, а картинка.

MtW>> Даю пояснение: PhiDo ── сторонний просмотрщик гипертекстовой
MtW>> фидопочты, и он открывает не один только векторный рисунок, но и всё
MtW>> окружающее его сообщение фидопочты.

ASy> Хорошо, есть эхи, поддерживающие данную технологию? Я хочу посмотреть,
ASy> как это выглядит.

Посмотри Ru.Anime в PhiDo. Правда, в силу специфики там иллюстрации будут
не векторные, а растровые, и не заююченные, а внешние (в Интернете лежащие),
а так всё то же самое: PhiDo покажет сообщение, а в сообщении картинку или
несколько картинок.

MtW>> Если же мы говорим не о флоппинете в узком смысле, а вообще об
MtW>> оффлайновом чтении Фидонета, то и тут, опять же, опасаться нечего.

ASy> Я и говорю об оффлайновом чтении. Ты же или тянешь фидо в инет -
ASy> или предлагаешь гонять ююки только потому, что у тебя нет фэх и ты
ASy> не хочешь разобраться с ними и настроить фэхопроц. Там, кстати, все
ASy> просто как швабра.

Тогда простой вопрос.

У тебя также конфигурация включает в себя условные выражения в зависимости
от переменной [module], как в изложенном ниже примере?

include /fido/etc/husky/common.cfg
include /fido/etc/husky/packer.cfg
include /fido/etc/husky/paths.cfg
include /fido/etc/husky/fpaths.cfg

if [module] == hpt
include /fido/etc/husky/general.cfg
elseif [module] == htick
include /fido/etc/husky/fgeneral.cfg
else
include /fido/etc/husky/nlgeneral.cfg
endif

include /fido/etc/husky/links.cfg

if [module] == hpt
include /fido/etc/husky/files.cfg
include /fido/etc/husky/route.cfg
elseif [module] == htick
include /fido/etc/husky/ffiles.cfg
endif

include /fido/etc/husky/StdAreas.cfg

CommentChar ;

if [module] == hpt
include /fido/etc/husky/areas.cfg
include /fido/etc/husky/ccopies.cfg
elseif [module] == htick
include /fido/etc/husky/fareas.cfg
include /fido/etc/husky/announce.cfg
endif

MtW>> Во-первых, браузер может открыть файл с диска с той же (или даже
MtW>> большей) лёгкостью, что и из Интернета.

ASy> А откуда он возьмет мультимедийный контент?

Из UUE декодирует же. Если это картинки.

Если ты имеешь в виду более тяжёлый мультимедийный контент (видео, например),
то скажи об этом ── обсудим.

MtW>> Во-вторых, фэхи равны UUE в оффлайновости (если на узле есть фэхи) и
MtW>> даже чуть уступают (если на узле нет фэх, так что файлы надо фрекать
MtW>> по межузловому соединению или скачивать с интернетовского FTP).

ASy> Ну тут уже выбор аплинка. Счас с этим нет проблем.

Что ты имеешь в виду? (С чем именно нет проблем?)

MtW>>>> Вообразим себе постпроцессор, который обозревает все пакеты
MtW>>>> фидопочты после распаковывания их эхопроцессором, находит в
MtW>>>> этих пакетах фидонетовские руны (Markdown-подобную разметку)
MtW>>>> иллюстраций и тотчас же запрашивает иллюстрации из
MtW>>>> P2P-распределённой файловой системы IPFS. Тогда, даже и сидючи
MtW>>>> без Интернета, иллюстрации ты эти мог бы лицезреть невозбранно,
MtW>>>> так как у тебя в IPFS они уж были б.

ASy> А для меня дурака можно подробнее? Контент не вырастает просто так сам.
ASy> В любой файловой системе...

Есть такая штука ── P2P-распределённая файловая система IPFS. Установив себе
её поддержку, можно в дальнейшем складывать в неё файлы (они тогда копируются
в базу данных, хранимую на диске) и брать из неё файлы (они тогда берутся из
базы данных на диске, а если там отсутствуют, то берутся по Интернету у других
людей, также установивших IPFS и имеющих у себя этот файл).

Вообразим себе постпроцессор, который обозревает все пакеты фидопочты сразу
после распаковывания их эхопроцессором (а тогда-то Интернет ещё есть!), находит
в этих пакетах фидонетовские руны (Markdown-подобную разметку) иллюстраций
и тотчас же запрашивает иллюстрации из P2P-распределённой файловой системы
IPFS. Тогда иллюстрации эти невозбранно из Интернета попадают на диск в базу
данных IPFS.

Тогда в дальнейшем, даже и сидючи без Интернета, иллюстрации ты эти мог бы
лицезреть невозбранно, так как у тебя в IPFS они к тому времени были бы.

ASy>>> Неужели сложно будет научить редактор кешировать скачаное
ASy>>> из инета?
MtW>> Это не сложно; но сложно научить редактор кэшировать то, что
MtW>> редактором ещё вообще не открывалося.

ASy> И не надо. Человеку это неинтересно - зачем ему тратить трафик и ресурсы?

А затем, чтобы в дальнейшем, даже и сидючи без Интернета, иллюстрации (заранее
скачанные) лицезреть невозбранно, так как в кэше они к тому времени были бы.

MtW>> Обрабатывать принятую (но ещё не открытую редактором) фидопочту
MtW>> способен только эхопроцессор (тоссер) или запущенный им обработчик
MtW>> (постпроцессор). Другого пути к этому идеалу быть не может.

ASy> Минимизировать трафик и дисковое пространство - это в том числе то,
ASy> на чем счас еще может выехать фидо. Иначе собачка умрет.

Я не согласен с этим утверждением. Считаю справедливым утверждение отчасти
противоположное: для выживания Сеть Фидонет должна перестать быть текстовою,
в её сообщениях должна появиться возможность либо непосредственной (в UUE),
либо опосредованной (в UUE в другой эхе, в файле в фэхе, в файле в IPFS,
в файле по фреку, в UUE нетмейлом по роутингу) появления нетекстовых данных
различного формата: векторных иллюстраций, растровых иллюстраций, звукозаписей,
видеозаписей. В противном случае Сеть Фидонет окончательно проиграет идущее уж
состязание её с новейшими социальными сетями, которое Фидонет может и выиграть
благодаря очевидным своим достоинствам, из которых первым является отсутствие
рекламы, а вторым является отсутствие гиперцентрализации расходов и связанных
с этим ограничений (вызванных тем, что пока ещё центральный сервер может у себя
хранить меньше, чем каждый из большинства конечных пользователей, что доказано
удобствами от перехода к файлообмену, наблюдаемыми распространителями видео).


Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]

... почему казахи Омск "коверкают", а ты им позволяешь? (Волков в Ru.Spelling)
--- Знаешь ли ты, Alexandr, что "надаренный" не пишется через "ё"?
Ответить с цитированием
  #374  
Старый 11.10.2016, 21:36
Alexandr Solov'yev
Guest
 
Сообщений: n/a
По умолчанию Отображение иллюстраций из ююков и фэх в векторном гипертекстовом

Alexandr Solov\'yev написал(а) к Mithgol the Webmaster в Oct 16 20:44:10 по местному времени:


Да не заглючит твой компьютер во веки веков, о Mithgol!

11 Окт 16 14:47, ты писал(а) мне:
-=скиип=-

MtW> С немалым сожалением вижу, что вопрос жидокащенизма (и, шире,
MtW> еврейский вопрос в целом) подменяется вопросом о 'люлюках'; это, вне
MtW> всякого сомнения, форма невротического замещения, или
MtW> пост-травматического триггера, или чего-то ещё в этом же роде
MtW> внерассудочного, позволяющего проигнорировать
MtW> внетехнологический расовый смысл того инцидента и прецедента.
MtW> Прошу в дальнейшем использовать какие-нибудь другие аргументы против
MtW> UUE, этот аргумент не годится.

Дело не в жидокащенизме и даже не в антисемитизме (расизме, etc). Дело в прецеденте. Имевшем место. На месте SKL могла быть любая другая эха. Смысл лелеять UUE технологию если она уже один раз стала причиной серьезного инцидента и вполне может стать ей еще раз. Почему не убрать грабли?

MtW>>> Во-первых, если я правильно понимаю, фрек (файловый запрос)
MtW>>> никак не возможно отправить аплинку и получить от аплинка
MtW>>> отклик без того, чтобы заодно не взять у него всю новую почту
MtW>>> (и, может быть, также свою ему выслать), а это дольше, чем
MtW>>> запрос к FTP.
ASy>> 1. При современных скоростях это "дольше" сколько займет секунд?
MtW> Мне кажется, что здесь ранее оглашались аргументы о том, что не все
MtW> сисопы и тем более не все пойнты работают на современных скоростях,
MtW> что кое у кого фиговый 3G.

Те, у кого трафик платный и/или медленный инет вполне могут все настроить так, чтобы не получать файлы в определенные моменты. Но никто не полезет фрекать на малой или дорогой скорости.

ASy>> 2. Фрекать необязательно именно с аплинка.
MtW> Пожалуй, этот аргумент справедлив. Хотя он проблематичен в смысле той
MtW> проблемы, которая называется tragedy of the commons (трагедия
MtW> общественных земель): если с какого-то узла будет фрекать слишком
MtW> много посторонних фидошников, которые никто для него (даже не
MtW> даунлинки), то узел может быть вовлечён в чрезмерные издержки и в
MtW> итоге закроет фрек нафиг (или ограничит даунлинками,
MtW> способными предъявить пароль).

Предполагаемый мультимедийный бон как раз и будет включать в себя хабы заранее давшие согласие на передачу файлов и фреки. И, возможно, с FTP. Или иными способами файлоотдачи.

MtW>>> Формирование файлового запроса (фрека) ── простое дело, так что
MtW>>> его в Голдеде можно видеть реализованным;
ASy>> Именно так. Все уже готово. Пользователи голдедов смогут
ASy>> получить контент. А если они его смотрят через жжжж, то это их
ASy>> выбор редактора.
ASy>> :-)
MtW>>> но речь же идёт вдобавок об отображении отклика, так что надо
MtW>>> учить просмотрщик дожидаться ответа мейлера; а найдутся ли
MtW>>> программисты, на это непростое дело готовые решиться?

А это надо? Фрек ушел - файл пришел. Никто за неимоверной скоростью не гонится.

ASy>> Просмотровщику ничего не нужно ждать. Он должен знать, где лежит
ASy>> файл. Сфреканый или полученный по фэхе - ему все равно.
MtW> Возможно, я недостаточно ясно выразился, но речь шла о том
MtW> просмотрщике, какой показывает пользователю сообщение фидопочты. Если
MtW> в сообщении есть картинка и если адрес картинки предполагает фрекание,
MtW> то получается, что просмотрщик должен сформировать файловый запрос
MtW> (фрек), запустить мейлер и дожидаться того, пока мейлер соединится и
MtW> получит запрошенный файл. Не правда ли?

Если пользователь отказался от файлэхи, то вариант только фрек. Нормально организованный редактор тут же запакует его на куда надо (или даст команду на паковку), а нормальный мейлер тут же отправит этот запрос куда сказано.

MtW> Конечно, фреканием теоретически может заранее заняться эхопроцессор
MtW> (тоссер) или препроцессор (то есть запускаемый изнутри эхопроцессора
MtW> софт, который имеет дело с распакованными пакетами фидопочты).

Зачем громоздить? При чем тут эхопроцессор? Нужен всего лишь трекер, который быстро упакует фрек на нужный узел. Если уж так горит. Не горит - фрек уйдет при следующем штатном сканировании баз.

MtW>>> Сам же я НTick не употребляю и фэх не имею, так что на опыте
MtW>>> не мог испытать правоту или неправоту вышеизложенного
MtW>>> впечатления.
ASy>> Вот теперь я понял, откуда такая антипатия к фэхам.
MtW> Предполагаю, что я не единственный из числа сисопов, фэх не имеющих.
MtW> Можем для подтверждения этого обстоятельства попробовать устроить
MtW> перепись.

Не так много, как тебе кажется. В основном это будут ноды на облаках где места для фэх мало. Или софт не позволяет их иметь. Подавляющее большинство фэхи имеет.
Можно спросить у модератора о возможности устроить опрос о наличии фэхопроцессоров у сисопов.

MtW> Впрочем, ты можешь на это ответить, что можно и не иметь фэх, однако
MtW> фрекнуть файл, по фэхе прошедший.

Именно это как раз и нужно при слабой сети или дорогом трафике.
Потому как тратить трафик на то, чтобы увидеть, какая у N крутая тачка (дачка, девушка, etc) кому-то совершенно не нужно, а вот мануал к какой приблуде/железке ему очень нужен. Он фрекает именно его.

MtW>>>>> Простая пользовательская машина может любым современным
MtW>>>>> браузером Интернета открывать SVG. (В роли браузера может
MtW>>>>> выступать Mozilla Firefox, Google Chrome, Opera и др.)
ASy>>>> Значит, без постоянного доступа в инет и стороннего ПО читать
ASy>>>> такие сообщения невозможно?
MtW>>> Доступа в Интернет не нужно. Браузер может открыть файл с диска
MtW>>> с той же (или даже большей) лёгкостью, что и из Интернета.
ASy>> А где на диске все это есть? Вот в фэхе все уже есть. Оттуда
ASy>> открывать - милое дело. И опять браузер. Без него никак?
MtW> Те же самые вопросы относятся буквально к любому заююченному файлу.
MtW> Где лежит на диске заююченный файл? Может ли GoldED+ обойтись без
MtW> внешних средств для его просмотра? (Просто так получилось, что
MtW> заююченные SVG можно открыть браузером.)

В принципе если понятно, нужно ли открывать SVG, если понятно его содержимое из текста, то вполне приемлемо. Но опять же теряется оффлайновая работа. Или нет?

ASy>>>> Тогда они влет попадут под 2.1.4. Уже без поправок, что голдед
ASy>>>> тоже понимает UUE и подобного. Один особо умный начнет травлю,
ASy>>>> другой его поддержит. А особо умных в фидо всегда хватало. :-)
ASy>>>> Не во всем, но нужно делать на них поправку.
MtW>>> Сложно веровать. Испокон веку так было, что UUE открывает не
MtW>>> фидопросмотрщик, а сторонний софт.
ASy>> Но даже голда умеет кодировку UUE превратить в читаемый обычным
ASy>> набором софта файл. Который откроется без доступа в инет и
ASy>> прочих плясок с бубнами.
MtW> Тогда при чём тут 2.1.4 вообще?

Быстрее начнут анноится по поводу шифрованного трафика. На UUE анноились, но как-то вяло. Наверное потому, что UUE давно уже гоняют по эхам.

ASy>>>>>> Значит надо ставить очередную приблуду?
MtW>>>>> Я надеюсь, ты не ожидал того, что существующая приблуда
MtW>>>>> (GoldED+) неожиданным и волшебным образом начнёт в своём
MtW>>>>> алфавитно-цифровом окошке отображать также и растровую да
MtW>>>>> векторную графику?
ASy>> Нет. Но отобразит текст. Читаемый. А не крокозяберы.
MtW> Дык что ж поделать, когда это не текст, а картинка.

Тогда должно быть понятно, что это картинка.

MtW>>> Даю пояснение: PhiDo ── сторонний просмотрщик гипертекстовой
MtW>>> фидопочты, и он открывает не один только векторный рисунок, но
MtW>>> и всё окружающее его сообщение фидопочты.
ASy>> Хорошо, есть эхи, поддерживающие данную технологию? Я хочу
ASy>> посмотреть, как это выглядит.
MtW> Посмотри Ru.Anime в PhiDo. Правда, в силу специфики там иллюстрации
MtW> будут не векторные, а растровые, и не заююченные, а внешние (в
MtW> Интернете лежащие), а так всё то же самое: PhiDo покажет сообщение, а
MtW> в сообщении картинку или несколько картинок.



MtW>>> Если же мы говорим не о флоппинете в узком смысле, а вообще об
MtW>>> оффлайновом чтении Фидонета, то и тут, опять же, опасаться
MtW>>> нечего.
ASy>> Я и говорю об оффлайновом чтении. Ты же или тянешь фидо в инет -
ASy>> или предлагаешь гонять ююки только потому, что у тебя нет фэх и
ASy>> ты не хочешь разобраться с ними и настроить фэхопроц. Там,
ASy>> кстати, все просто как швабра.
MtW> Тогда простой вопрос.
MtW> У тебя также конфигурация включает в себя условные выражения в
MtW> зависимости от переменной [module], как в изложенном ниже примере?
MtW> include /fido/etc/husky/common.cfg
MtW> include /fido/etc/husky/packer.cfg
MtW> include /fido/etc/husky/paths.cfg
MtW> include /fido/etc/husky/fpaths.cfg

Подобное у меня существует. Конфиг порезан. Правда на другие части. Типа areas.cfg, point.cfg, etc. Излишеств нет. Зачем лишнее городить?

MtW>>> Во-первых, браузер может открыть файл с диска с той же (или
MtW>>> даже большей) лёгкостью, что и из Интернета.
ASy>> А откуда он возьмет мультимедийный контент?
MtW> Из UUE декодирует же. Если это картинки.

А UUE откуда возмется?

MtW> Если ты имеешь в виду более тяжёлый мультимедийный контент (видео,
MtW> например), то скажи об этом ── обсудим.

Да любой контент. Должен остаться выбор у пользователя - получать его или нет.

MtW>>> Во-вторых, фэхи равны UUE в оффлайновости (если на узле есть
MtW>>> фэхи) и даже чуть уступают (если на узле нет фэх, так что файлы
MtW>>> надо фрекать по межузловому соединению или скачивать с
MtW>>> интернетовского FTP).
ASy>> Ну тут уже выбор аплинка. Счас с этим нет проблем.
MtW> Что ты имеешь в виду? (С чем именно нет проблем?)

С выбором аплинка для мультимедийных эх. Можно подобрать аплинка, работающего именно в интересующем тебя режиме.

MtW>>>>> Вообразим себе постпроцессор, который обозревает все пакеты
MtW>>>>> фидопочты после распаковывания их эхопроцессором, находит в
MtW>>>>> этих пакетах фидонетовские руны (Markdown-подобную разметку)
MtW>>>>> иллюстраций и тотчас же запрашивает иллюстрации из
MtW>>>>> P2P-распределённой файловой системы IPFS. Тогда, даже и
MtW>>>>> сидючи без Интернета, иллюстрации ты эти мог бы лицезреть
MtW>>>>> невозбранно, так как у тебя в IPFS они уж были б.
ASy>> А для меня дурака можно подробнее? Контент не вырастает просто
ASy>> так сам. В любой файловой системе...
MtW> Есть такая штука ── P2P-распределённая файловая система IPFS.
MtW> Установив себе её поддержку, можно в дальнейшем складывать в неё файлы
MtW> (они тогда копируются в базу данных, хранимую на диске) и брать из неё
MtW> файлы (они тогда берутся из базы данных на диске, а если там
MtW> отсутствуют, то берутся по Интернету у других людей, также
MtW> установивших IPFS и имеющих у себя этот файл).
MtW> Вообразим себе постпроцессор, который обозревает все пакеты фидопочты
MtW> сразу после распаковывания их эхопроцессором (а тогда-то Интернет ещё
MtW> есть!), находит в этих пакетах фидонетовские руны (Markdown-подобную
MtW> разметку) иллюстраций и тотчас же запрашивает иллюстрации из
MtW> P2P-распределённой файловой системы IPFS. Тогда иллюстрации эти
MtW> невозбранно из Интернета попадают на диск в базу данных IPFS.
MtW> Тогда в дальнейшем, даже и сидючи без Интернета, иллюстрации ты эти
MtW> мог бы лицезреть невозбранно, так как у тебя в IPFS они к тому времени
MtW> были бы.

Ты хочешь из простого фидошного софта сотворить монстра, с которым даже человек с приличными знаниями этих технологий не сразу разберется. Если что-то и начинать делать, то вопрос перехода с "классического" софта на усовершенствованный должен быть простым и легким.

ASy>>>> Неужели сложно будет научить редактор кешировать скачаное
ASy>>>> из инета?
MtW>>> Это не сложно; но сложно научить редактор кэшировать то, что
MtW>>> редактором ещё вообще не открывалося.
ASy>> И не надо. Человеку это неинтересно - зачем ему тратить трафик и
ASy>> ресурсы?
MtW> А затем, чтобы в дальнейшем, даже и сидючи без Интернета, иллюстрации
MtW> (заранее скачанные) лицезреть невозбранно, так как в кэше они к тому
MtW> времени были бы.

Он все равно не будет смотреть крутую тачку/дачку/девочку сисопа N. И нахрена они ему в кеше?

MtW>>> Обрабатывать принятую (но ещё не открытую редактором) фидопочту
MtW>>> способен только эхопроцессор (тоссер) или запущенный им
MtW>>> обработчик (постпроцессор). Другого пути к этому идеалу быть не
MtW>>> может.
ASy>> Минимизировать трафик и дисковое пространство - это в том числе
ASy>> то, на чем счас еще может выехать фидо. Иначе собачка умрет.
MtW> Я не согласен с этим утверждением. Считаю справедливым утверждение
MtW> отчасти
MtW> противоположное: для выживания Сеть Фидонет должна перестать быть
MtW> текстовою, в её сообщениях должна появиться возможность либо
MtW> непосредственной (в UUE), либо опосредованной (в UUE в другой эхе, в
MtW> файле в фэхе, в файле в IPFS, в файле по фреку, в UUE нетмейлом по
MtW> роутингу) появления нетекстовых данных различного формата: векторных
MtW> иллюстраций, растровых иллюстраций, звукозаписей, видеозаписей. В
MtW> противном случае Сеть Фидонет окончательно проиграет идущее
MtW> уж состязание её с новейшими социальными сетями, которое Фидонет может
MtW> и выиграть благодаря очевидным своим достоинствам, из которых первым
MtW> является отсутствие рекламы, а вторым является отсутствие
MtW> гиперцентрализации расходов и связанных с этим ограничений (вызванных
MtW> тем, что пока ещё центральный сервер может у себя хранить меньше, чем
MtW> каждый из большинства конечных пользователей, что доказано удобствами
MtW> от перехода к файлообмену, наблюдаемыми распространителями видео).

Ты хочешь сделать из фидо плохое подобие форума. Это его убьет.

Всего наилучшего в этом лучшем из миров!
Alexandr Solov'yev

... Reset - не кнопка, а горькая необходимость
--- Oldest fimooznik 1.1.5-b20160322
Ответить с цитированием
  #375  
Старый 28.11.2016, 12:11
Mithgol the Webmaster
Guest
 
Сообщений: n/a
По умолчанию Подсистема редактирования и удаления ранее отосланных сообщений эх

Mithgol the Webmaster написал(а) к Alexandr Solov\'yev в Nov 16 08:22:22 по местному времени:

Знаю уж, 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> соответствующего эхе XOFCНUBSLST по её имени, то можно (и даже разумно)
MtW> попробовать ftp://fido.hubahuba.su/XOFCНUBS.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...g/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.
>
> TНE BROADCAST FEATURE ONLY WORKS ON MESSAGES TНAT WERE ORIGINALLY
> TOSSED TO A SQUISН AREA BY SQUISН 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. Нowever, Squish will
> only process update/delete messages if it receives them from the
> node specified by -u.)
>
> For example, the following definition sends PVT_ECНO 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 PVTECНO \path\pvtecho -$ 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 "SQUISН
> 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-пакет ifgate2.14tx8.10-21s390x.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, да*и*тот, если*правду сказать, недодокументирован; в*прежних*же эхопроцессорах, типа*НPT, идёт*разве*что устранение*багов, не*более).

Хорошо*ещё, что*это только в*строгом*смысле. В*практическом*же смысле задача сбора*данных, содержащихся в*пришедшей фидопочте, может*решаться не*одним*лишь эхопроцессором, но*также и*препроцессором, то*есть такою программою или*таким скриптом, который запускается после распаковывания так*называемых бандлов (архивов пришедшей фидопочты), но*перед собственно*тоссингом (то*есть перед раскладыванием в*базе той*фидопочты, которая извлечена из*пакетов фидопочты, и*тем*более перед последующим удалением этих*пакетов).

Такому препроцессору, впрочем, пришлось*бы собирать собственную базу*сведений, и*притом (с*целью поддержки этой*базы в*актуальном состоянии) предусмотреть, скорее*всего, какую-то осмысленную реакцию на*действия сисопа, который*ведь способен, между*прочим, не*только сочинять исходящую фидопочту, но*также*ещё и*заниматься удалением и*даже редактированием любой предшествующей фидопочты.

Это драма превозмогания, но*это*ещё не*трагедия*погибели.


Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]

... Я хочу туда-а-а-а!!!! Я балдею! Какие деревья! Какие листья! (Нitana)
--- Эшелону: NAVCM Гамма Горизонт Guppy NSS rita ISSO submiss ASDIC .tc
Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 10:18. Часовой пояс GMT +4.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc. Перевод: zCarot