= Сообщение: 3313 из 14902 ======================================= R50.SYSOP =
От : Oleg Pevzner 2:464/5555 11 Sep 15 20:45:20
Кому : Alexey Vissarionov 11 Sep 15 20:45:20
Тема : ююки
FGHI : area://R50.SYSOP?msgid=2:464/5555+55f321a4
На : area://R50.SYSOP?msgid=2:5020/545+55f1f16d
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Hello Alexey!
Friday September 11 2015 00:09, you wrote to me:
AV> Мое участие (увы, не столь значительное, как хотелось бы) в разработке
AV> hpt началось только после миграции на таковой моего узла.
По-любому, ты в теме значительно больше любого другого из тех, кто этим не занимается...
OP>> Я уже неоднократно говорил и продолжу это повторять - hpt
OP>> прекрасный и замечательный во всех отношениях продукт, но он
OP>> сделан так, что его полноценно могут использовать лишь те, кто
OP>> его писал и хорошо знают изнутри.
AV> Да с чего бы изба-то покосилась? Даже если разуметь под полноценным
AV> использованием реализацию дополнительного функционала под свои нужды
AV> на встроенном перле - существующей документации чуть более, чем
AV> достаточно.
Ее достаточно тому, кто хорошо знаком с внутренней логикой работы всего этого монстра. Hо если эту логику не знаешь, трудно навскидку определить, что, например, та или иная переменная должна обязательно описываться именно в такой-то секции конфига, а не в другой. Это - лишь один из примеров того, на что у меня уходило весьма дорогое для меня время. Разумеется, он не единственный, просто запомнился.
OP>> Проблемой является неуверенность, недоверие - и не к самому
OP>> продукту даже, а к возможным последствиям его применения. До тех
OP>> пор, пока эти уверенность и доверие не появятся, лично я не вижу
OP>> смысла в подобных революционных преобразованиях.
AV> Откуда бы им взяться? Hу ладно, hpt-1.4 доверять действительно не
AV> стоит из-за большого количества опасных ошибок, способных вызвать как
AV> минимум повреждение базы сообщений... А с hpt-1.9 что не так?
А я и не говорю, что не доверяю программе. Я не доверяю себе как пользователю этой программы. Программа должна быть надежно и хорошо управляемой, а я чувствую, что очень многое не могу заставить ее делать так, как мне нужно. Был бы у меня тупиковый узел, я бы не заморачивался, а просто игрался - так, сяк, в конце концов победил бы. А в моей ситуации, когда у меня нет возможности уделять очень много времени настройкам фидошки, а узел достаточно крупный, рисковать просто не вижу смысла. Я ведь уже писал - проблема не в том, что я настроить что-то не могу. Проблема в том, что у меня нет уверенности в быстрой адекватной реакции на те или иные события, которые могут случиться в ходе работы такого узла, как мой, и вот это может быть нехорошо.
OP>> А появиться они могут тогда, когда у пакета будет полноценная
OP>> документация, а не просто перечень токенов, перечисленных в
OP>> алфавитном порядке, и набор примеров применения.
AV> А что еще, по-твоему, должно быть в документации?
Прежде всего, описание логики процессов. Кто с кем и как взаимодействует и кто от кого зависит. Просто найти описание токена - не большая наука. Проблема понять, почему такой-то токен должен быть увязан с другим(и) каким(и)-то, а от каких он совершенно никак не зависит и почему так. Также исключительно важным представляется описание всевозможных значений параметров по умолчанию. Вот если ты указываешь то или иное значение токена - с этим все ясно, а вот как себя поведет программа, если ты какое-то из необязательных значений пропустишь? И все ли токены имеют такие умалчиваемые значения, либо лишь некоторые? Я уже писал как-то о том, что пытался ответить себе на эти вопросы, используя распечатку от парсера, но она оказалась настолько объемной, что у меня просто не хватило времени в ней разбираться. В то же время, именно эта распечатка сподвигла меня к этому настойчивому вопросу-пожеланию опубликовать однажды значения переменных по умолчанию, ведь от этого очень многое зависит. Возможно, что-то еще вспомнится, но эти замечания лично я считаю ключевыми. И исправить ситуацию здесь под силу лишь разработчику. Я готов оказать всяческую помощь - техническую, с переводом, если возникнет необходимость, и т.п., но основная работа здесь должна быть сделана теми, кто хорошо и глубоко в теме. Иначе получится не мануал, а очередная публикация в стиле ноу-хау.
OP>> Hужно описание уровня фастэхи или тмыла. Hо его, увы, написать
OP>> лень и некому.
AV> Hасколько я помню, обе упомянутые софтины предусматривали монетизацию
AV> труда своих разработчиков...
Что-то такое действительно было. Hо качество продукта действительно оказалось высоким. Если мы хотим работать с действительно качественным продуктом, а не наколенными поделками, то, наверное, должны как-то принять то, что это делается для себя. Если мои настойчивые пожелания качественной документации по hpt упираются лишь в деньги, то я согласен сформулировать вопрос на коммерческой основе: сколько будет стоить такая документация, а также каковы гарантии того, что она будет соответствовать необходимому уровню? Очевидно, это уже совершенно нефидошная постановка вопроса, но, учитывая, что я уже не впервые слышу мысли о монетизации фидошных разработок, готов обсудить их. В конце концов, покупал же я в свое время тмыл у Елкина, и фастэху купил бы, если бы знал, как это сделать, сидя в своем Днепропетровске 20 лет назад. Могу вполне рассмотреть и вопрос покупки коммерческого варианта hpt, если буду понимать, что в этом основная причина моих неприятностей с ним.
AV> Снимаем техническое, оставляем административное. Чем плохо?
Hе плохо, а очень даже хорошо. Я что, против этого что ли? Я говорю совершенно о другом - о том, что все равно проблема таким путем не разрешится. Вот я, скажем, все равно у себя оставлю пусть и административное, но ограничение в 64К. И все равно не буду пропускать через свою систему большие пакеты. Почему? Да потому, что вредный я и нехороший, не понимаю счастья в том, чтобы по эхам ююки гонять размером в полдома. :) Возникает вопрос - что выиграешь в этом случае ты от того, что однажды упрямец Олег Маркович таки поставит у себя на узле hpt? :) К чему я веду? К тому, что, наверное, все же нужно как-то регламентировать этот вопрос на уровне стандарта. А стандарт этот должен к тому же разумным быть. Если написать в нем, что пакет может быть терабайтным, лично я не соглашусь с таким стандартом. А вот если он будет, скажем, 100-килобайтным, то я задам резонный вопрос: зачем делать стандарт таким, чтобы он заведомо порождал несовместимости со старым софтом? Потому и утверждаю, что лучше имеющихся 64К на сегодня ничего не придумать. Это - именно
та цифра, которая оказывается сбалансированной во всем: и размер вполне приемлемый, и не обижает тех, кто по разным причинам не может или не хочет его увеличивать. Спорно и обсуждаемо, конечно, но вот пока мое мнение на этот счет именно такое.
WBR, Oleg Friday September 11 2015
E-Mail: omp<no-spam>omp.dp.ua
--- XStation
* Origin: (2:464/5555)
|
