Здравствуйте, Privalov, Вы писали:
NR>>Ответов не будет по другой причинеАвтор: Sheridan
Дата: 23.08.10
P>Ничего себе! Как тебе удалось? Что ты ему сказал? Такого я не видел ни разу. 
Да уж... Нет, пальцы я ему не ломал, демократизатором по почкам — тоже не бил и даже не угрожал. Просто я — гениальный полемист и непревзойденный оратор, обладающий к тому же непревзойденной харизмой. Так что если что — вы знаете где меня найти.
ЗЫ. Нет, памятник в мою честь не нужен, достаточно просто разместить мой ник на главной странице КЫВТа.
M>> Так все так и делают. За исключением случаев, когда нужно выбрать другой порт. Я лично тебе это говорил раза три.
S>А чего тогда на меня накинулись то?
Потому что ты нихрена не знаешь про HTTP и порешь чушь про тот же REST, хотя до сих пор не удосужился ничего про него прочитать. Но мнение имешь, да. Про тот же www ты несешь настолько запредельный бред, что противно слушать.
S>
M>> S>Итак. Почему вы перед тем, как указать в своем софте порт по умолчанию, не сверяетесь с http://www.iana.org/assignments/port-numbers ? Вы понимаете, что поступаете просто непрофессионально и эгоистично по отношению к своим коллегам?
M>> 1. Больше половины сервисов, указаных там, не существует в природе.
S>Мало ли что там не существует. Они отмечены в документе? Да. Значит, надо считаться.
Если они не существуют, зачем с ними считаться?
M>> 2. Больше половины оставшейся половины являются специфическими и редко используемыми протоколами
S>И это както влияет на то, что они там есть?
Это влияет на то, что если я использую порт, «занятый» каким-нибудь Submission, вероятность нарушения работы кого-либо где-либо стремится к нулю, и этим можно пренебречь, если удобство от использования другого сервиса на этом порту перевешивают любые могущие возникнуть проблемы. Да-да, это тот самый SHOULD, окторый ты ухитряешься интерпретировать вразрез с RFC.
M>> 3. Использование приложения на зарегистрированном/well-known порту не нарушает работу других приложений и/или не нарушает работу других приложений на том же порту
S>Перефразируй. А то какоето масло маслянное получается. Да, оно не нарушает работу других приложений, но оно усложнит несколько поднятие сервиса, который должен быть на этом порту. както так.
Совсем не так. Оно может усложнить, а может и не усложнить. Если усложняет — ну так поэтому 99% приложений и имеют возможность в настройках сменить порт
M>> 4. Выгода от использования приложения превышает любые неудобства, связаные с использованием того или иного порта
S>Ну конечно же, выгода. Ага. Как всегда бабло (некие бонусы, не обязательно денежные) побеждает здравый смысл.
Выгода от использования — это не всегда бабло. Может, я не совсем верно использовал термин, но тем не менее.
S>
M>> Почему ты ничего не хочешь про это слышать? Это не бред. Но для этого надо открыть и прочитать хотя бы одну ссылку, что мы тебе приводим. Почему ты их не читаешь? Почему ты вообще ни читаешь ничего про то, о чем ведется разговор?
S>Читаю, начитался уже по самое нехочу.
Незаметно.
ЗдесьАвтор: Sheridan
Дата: 06.08.10
особенно показательно.
M>> 1. HTTP — это всего лишь протокол прикладного уровня. В нем ничего магического и мистического. Это — всего лишь протокол. По нему есть RFC 2616, про который тебе уже говорилиАвтор: NavuhodonosoR
Дата: 17.08.10
.
S>Верно.
M>> HTTP — это вдоль и поперек изученный протокол. Его поведение прекрасно известно. Его поведение предсказуемо.
S>Все верно.
M>>Почему его нельзя использовать?
S>Во первых я говорил про 80й порт. Незачем на него вешать свой сервис.
Почему? Где в RFC по HTTP написано, что это нельзя?
S>Во вторых ты сам должен понимать, что насколько бы не был хорош http — он не подходит для вех подряд задач.
А кто-то говорит, что он подходит для всех подряд задач? Тут
никто, кроме тебя такое не говорит.
S>И на самом деле если разрабатывать для каждой задачи свой протокол — он будет более эффективно работать, нежели http.
Далеко не факт. И это очевидно. HTTP существует уже больше десятка лет. В него вложено сил на разработку на много порядков больше, чем себе может позволить какая-нибудь средней руки фирма. То же относится ко многим другим протоколам.
S>Но к сожалению эффективность сейчас на последнем месте. На первом месте, к сожалению, скорость разработки, потому как чем быстрее накалякать софтину, тем быстрее заплатят.
Если бы все шли по твоему пути, мы бы до сих пор были на уровне MULTIVAC'а. Берешь в руки Линукс (за который никто не платит) и смотришь, како дикое количество стандартных протоколов там используется. И практически никто никогда в том же Линуксе не придумывает свои протоколы. Интересно, почему? Хотя, такой вопрос или желание посмотреть тебе лично почему-то никогда не приходит в голову? Странно да?
M>> 2. Есть такая архитектура приложений, называется REST. Так же, как MVC, MVVM, SOA и толпы других.
S>Ну, я бы не назвал это архитектурой. Это скорее правила организации обмена данными. Лично я использовал бы обычный коннект к БД вместо этого подобия.
Угу, весь мир называет это архитектурой, один Шеридан, как всегда, имеет собственное мнение, ничего общего с реальностью не имебщее. И нет, это не только правила обмена данными. Но ведь для этого надо почитать больше, чем одну ссылку, но зачем?
M>> И множество задач прекрасно ложится на эту архитектуру. Что теперь, не использовать ее? Почему? Только потому, что ты так сказал?
S>А если подкрутить — то и все лягут, да?
Так говоришь
только ты.
S>То что многие задачи по большому счету и так следуют тем правилам, которые описаны в ресте (разделение по объектам, дерево, методы create/edit/delete...) еще не значит что этот рест — панацея от всех бед. Под каждую задачу нужно подбирать свое! Под каждую!
А кто-то с этим тут спорит? Шеридан, борьба с ветряными мельницами хороша только в книгах. В реальной жизни — это жалкое зрелище.
M>> 3. Данные плюс состояние клиента — это не обязательно уникальные данные. Более того, если у тебя приложение типа хранилища документов (ключевые слова: Riak, CouchDB, MongoDB), то никакой уникальности в запросе к одному и тому же документу не будет. Сложность приложения не означает рост сложности данных. Процентов 90% данных существуют только на чтение и никогда не меняются. Что мешает их закешировать? Ничто.
S>Чтож, с кешем ты меня всетаки начинаешь убеждать. Хотя я еще и сомневаюсь в целесообразности.
Для того, чтобы иметь об этом представление и составлять хоть какое-то мнение, то надо хотя бы несколько лет с этим поработать. Ну или хотя бы умные книги читать типа
Web Caching или
high Performance Web Sites.
S>Дело в том, что все будет прекрасно кешироваться до тех пор, пока не наткнетесь на параноидальный прокси, который будет плевать на ваши заголовки и сам будет решать когда из кеша брать, а когда и "снаружи" пропустить.
Ну и на такие натыкаемся и? Тепрь перестать использовать этот протокол только из-за одного паранаидального прокси?
M>> 4. «От силы» 10-15% канала — это дохрена. Потому что это не только канал (что может измеряться гигабайтами данных экономии), но и экономия ресурсов сервера, которому не надо тратить время на вычисление этих ресурсов.
S>На деле 10-15% это по максимуму.
И у тебя, безусловно, есть статистика, это подтверждающая. Для того же сервиса линеек на повторных запросах с одного и того же хоста на одной картинке это может
сэкономитьАвтор: Sinclair
Дата: 07.04.08
(1 — 189/16057)*100=98.8% трафика на повторных запросах. А так как такие линеечки используются в основном на форумах с большим количеством просмотров страниц с одного хоста, то это дикая экономия трафика как для клиента, так и для сервера.
Для разных данных эта цифра может очень сильно варьироваться, конечно.
S> У меня домашний прокси экономит 3-5 процентов, и это при том, что пользователей немного, и все постоянно ходят по одному набору сайтов.
Дадада. Твой домашний прокси — это, безусловно, показатель. О да.
S>А насчет ресурсов я уже говорил: дешевле и проще проапгредить сервер, чем всех клиентов.
А при чем тут все клиенты? Зачем апгрейдить клиентов?
M>> Более того, даже обычное, грамотно спроектированное приложение использует не один, а несколько уровней кэширования данных — на уровне базы данных, на уровне самого приложения, на уровне представления данных. Если протокол предоставляет дополнительные возможности по кэшированию даггых, почему этим не воспользоваться?
S>Да просто потому, что это еще одно звено, которое может "поломаться". Просто потому, как это уменьшает надежность продукта.
Тогда давай вообще ничем не будем пользоваться, выкинем все компьютеры, потому что там таких звеньев — миллионы. Давай вообще будем пользоваться вообще только TCP, потому что только он более-менее «не ломается»
Что за чушь ты несешь?
M>> Потому что золотое правило программирования — не занимайся велосипедостроительством.
S>И похоже все вокруг просто фанаты этого правила. Возвели в абсолют, и скоро храм в честь Его откроют, да?
Именно. Если бы все программисты придерживались этого правила, то не было бы индусов, не было воплей про криворуких программеров и индусов и т.п. И вообще уже давно бы наступил золотой век. А то постоянно появляются всякие Шериданы, которые вместо того, чтобы взять уже готовый, отточены и отлаженый инструмент, начинают тратить время на написание глючных поделок.
S>Да только дело в том, что это не велосипед, да. Для каждой задачи надо заново продумывать ее протокол, только так можно добиться эффективности.
Нахрена для каждой задачи придумывать протокол? Ты лично в жизни не придумаешь ни одного протокола эффективнее какого-либо из существующих. Только википедия в списке прикладных протоколов приводит
несколько десятков названий. Свой протокол можно придумывать
только если не подходит ни один из существующих.
S>А все подряд под одну гребенку грести — это до добра не доведет.
Про одну гребенку говоришь
только ты.
S>>более того — позабудут вскоре про все остальные протоколы (что уже и наблюдается. Про irc кто-ть помнит? а про nntp?)
M>> Эти протоколы менее удобны в использовании — вот и все. Удобны не значит легки. HTTP — далеко не такой легкий протокол, как кажется. Но он удобен в использовании. Естественно, не всегда. Но там, где он удобен в использовании, почему его не использовать?
S>Да почемуто выходит что он везде удобен. Куда не плюнь — удобен.
Об этом говоришь
только ты.
S>Только вот этом дерьмофлейме никто про другие протоколы даже и не вспомнил. Лично мне это говорит отнюдь не об удобности, а просто о привычках программистов. И мне эти привычки не нравятся.
В этом флейме и во многих других его просто удобно обсуждать. Так как ты про него ничего не знаешь вообше (хотя я сильно сомневаюсь, что ты знаешь что-либо про другие протоколы. Например, если бы обсуждали
AMQP или
XMPP, результат был бы абсолютно таким же).
M>> А почему не 80-й порт? Ты сам говоришь, что надо использовать тот порт, на котором приложение ожидает то, что указано в IANA. Если на 80-м порту ожидается HTTP, то почему приложение, использующее http, должно использовать какой-то другой порт? Только потому, что ты придумал себе какое-то определение для этого порта, которое сам формализовать не можешь и которое ничего не имеет общего с реальностью?
S>эх... Ты так ничего и не понял... Я требую чтобы вы валили с зарегестрированных в iana портов. Какие протоколы вы будете пользовать — мне по боку. Если конечно вы не реализуете сервис, который должен на сих портах висать. С http тут немного разговор отдельный, так как этим протоколом затыкаются сейчас все дырки.
Ээээ стоп. То есть ты мне все таки позволяешь на 80-й порт вешать сервис, работающий поверх HTTP? RSS, SOAP, XML-RPC, JSON-RPC, любое другое приложение, работаеющее поверх HTTP (типа
CouchDB)?
S>
M>> Может, пора остановиться и начать ... ну хотя бы читать приводимые тебе ссылки? А?
S>Ты до сих пор уверен что я их не читаю? Странно...
Абсолютно уверен. Иначе ты бы не повторял одну и ту же чушь по несколько раз.
Здравствуйте, NavuhodonosoR, Вы писали:
NR>Да уж... Нет, пальцы я ему не ломал, демократизатором по почкам — тоже не бил и даже не угрожал. Просто я — гениальный полемист и непревзойденный оратор, обладающий к тому же непревзойденной харизмой. Так что если что — вы знаете где меня найти.
Так ты бы лог, в крайнем случае, конспект беседы где-нибудь выложил, а? Народ у тебя поучился бы.
Здравствуйте, Sheridan, Вы писали:
S>Чтож, доля логики в ваших словах есть, у NavuhodonosoR хорошо получается доказывать
Содержание озвучишь? Хотелось бы знать количество логики в наших словах, абсолютное и относительное.
Здравствуйте, Privalov, Вы писали:
NR>>Да уж... Так что если что — вы знаете где меня найти.
P>Так ты бы лог, в крайнем случае, конспект беседы где-нибудь выложил, а? Народ у тебя поучился бы.
Акститесь, батенька! Какой лог может быть для беседы скайпом? Или может? Я — не умею
На самом деле в конечном итоге все свелось к следующему:
Шеридан признал, что его опыт не достаточно большой, чтобы его оппоненты принимали фразу "уж поверь моему опыту" в качестве весомого аргумента.
Шеридан признал, что целесообразность разработки собственного протокола мало коррелирует с экономией трафика.
Шеридан узнал, что такое мультиплексирование на протоколе HTTP.
Шеридан признал, что повсеместное применение протокола HTTP на 80 порту можно рассматривать как переход с L3 на L4 по модели ISO, то есть естественный эволюционный шаг.
А добился я этого просто наглядной демонстрацией противоречий в его рассуждениях, к тому же лишив его возможности промолчать, улыбнуться, проигнорировать мой аргумент и т.п.
Здравствуйте, NavuhodonosoR, Вы писали:
NR>Акститесь, батенька! Какой лог может быть для беседы скайпом? Или может? Я — не умею
Я в порядке.
Я рассматривал как возможность устной беседы, так и чата. Поэтому и спросил либо лог, либо конспект. Ясен пень, ставить распознаватель речи с записью в файл — это слишком.
[....]
Да, это немало. Подождем его следующих выступлений, посмотрим, как изменится характер его аргументов и реакция на аргументы оппонента.
NR>А добился я этого просто наглядной демонстрацией противоречий в его рассуждениях, к тому же лишив его возможности промолчать, улыбнуться, проигнорировать мой аргумент и т.п.
Понятно. В устном общении оппонента гораздо сложнее проигнорировать. Да и споришь та не с аргументами, а с их носителем, который, к тому же, все время в контексте.
Приветствую, NavuhodonosoR, вы писали:
NR> Шеридан признал, что его опыт не достаточно большой, чтобы его оппоненты принимали фразу "уж поверь моему опыту" в качестве весомого аргумента.
Да. Пожалуй для
множества народа местного это не может быть аргументом. Буду теперь эту фразу писать, когда действительно уверен, что по обсуждаемой теме опыта у меня больше.
NR> Шеридан признал, что целесообразность разработки собственного протокола мало коррелирует с экономией трафика.
Но коррелирует, и надо для каждой задачи выяснять — насколько. Ты это почему забыл дописать?
NR> Шеридан узнал, что такое мультиплексирование на протоколе HTTP.
Я это знал и раньше, не следует это сюда писать.
NR> Шеридан признал, что повсеместное применение протокола HTTP на 80 порту можно рассматривать как переход с L3 на L4 по модели ISO, то есть естественный эволюционный шаг.
Рассматривать да, можно. Только вот не вижу смысла в этом переходе. Кто-ть может внятно объяснить?
Здравствуйте, Sheridan, Вы писали:
Так и запишем: магия чарующего голоса Навуходоносора действует на Шеридана не более 6 дней
Впрочем, даже это является абсолютным рекордом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Здравствуйте, Sheridan, Вы писали:
S>Да. Пожалуй для множества народа местного это не может быть аргументом. Буду теперь эту фразу писать, когда действительно уверен, что по обсуждаемой теме опыта у меня больше.
"Не советую, молодой человек. Съедят". (c)
NR>> Шеридан признал, что целесообразность разработки собственного протокола мало коррелирует с экономией трафика.
S>Но коррелирует, и надо для каждой задачи выяснять — насколько. Ты это почему забыл дописать?
Если коэффициент корреляции меньше 0.95, это не корреляция.
Пто остальным вопросам — не знаток.
Приветствую, kochetkov.vladimir, вы писали:
k> Здравствуйте, Sheridan, Вы писали:
k> Так и запишем: магия чарующего голоса Навуходоносора действует на Шеридана не более 6 дней Впрочем, даже это является абсолютным рекордом.
Почему же, я реально стал поспокойнее воспринимать сабж. Как минимум — теперь понимаю, чем программисты руководствуются, когда начинают писать подобное...
NR>> Шеридан признал, что целесообразность разработки собственного протокола мало коррелирует с экономией трафика.
S>Но коррелирует, и надо для каждой задачи выяснять — насколько. Ты это почему забыл дописать?
Самое смешное, что в разных вариациях эту фразу произнесло с десяток человек раз двадцать, а то и пятьдесят. Но голоса в голове — это голоса в голове. Они важнее, умнее, правильнее и точнее, чем голоса реальные, и именно к ним надо прислушиваться.
Самое смешное и печальное заключается в том, что «чарующий голос Навуходносора» будет действовать от силы 3-4 месяца. А там все начнется по новой. Вы хотите пруфлинки? Их есть у меня:
http://rsdn.ru/forum/flame.comp/3566621.aspxАвтор: Mamut
Дата: 13.10.09
