Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DOOM, Вы писали:
DOO>>Ну и что тут смешного? Терминальный сервер был бы абсолютно нормальным решением — на уровне Citrix Metaframe, когда конечный пользователь даже не догадывается, что его приложение не локальное.
S>Подозреваю, что задержки убили бы фотошоп на корню.
Ну можно же было бы сделать сеть локальных провайдеров услуги Говоря твоими же словами.

S>Тем не менее, твои знания об сравнительных характеристиках протоколов существенно отстают от силы твоих убеждений.
Это тоже сильно необснованный наезд.


DOO>>А касательно убогости — ты опять лукавишь. Когда у тебя сервер легко обслужит 50000 соединений? Когда надо отдавать каждому клиенту по одной статической странице раз в полчаса?
S>В целом — да. Но держать по 2000 активных пользователей одновременно вполне возможно.
Что такое 2000 пользователей для крупного web-проекта? Один фиг понадобится ферма.

DOO>>Тот же Web2.0 предполагает постоянный обмен между клиентом и сервером. Если это будет Photoshop web edition — то страшно представить какой там пойдет обмен... Да еще и в Base64...
S>Откуда там возьмется base64?
Ну как же — знаменитый AJAX использует XML.HTTP, а XML, если ничего не менялось, не признает бинарные данные.

S>Я же говорю — ничего вы про http не знаете.
HTTP? Причем здесь он.

S>Кто сказал, что трафик будет большим? Веб-приложение предполагают исполнение части логики на клиенте. Запросто могу представить себе, что реальный обмен будет значительно меньше, чем для RDP.
Я себе представляю логику web адоба следующим образом:
закачка изображения на сервер, применения одного (или не одного) из фильтров, возврат изображения клиенту. ИМХО, трафик маленьким не будет.


DOO>>Кроме того, помимо просто обмена надо будет заниматься еще другими вспомогательными вещами — контроль сессии, аккаунтинг — все это в HTTP реализовано костылями и непонятно, какой смысл цепляться именно за него, при необходимости интенсивного обмена клиент-сервер, а также наличия богатого гуя на стороне клиента.
S>Не смешите мои тапочки. Всё в http нормально сделано. В том числе и методы балансирования нагрузки.
Конечно, в stateless протоколе, что там парится за балансировку нагрузки. Но это и оверхед свой создает.
Между прочим терминальных решений с нормальной балансировкой тоже пруд пруди.


DOO>>Кстати откуда ты взял оценку в 50 соединений на один RDP сервер?
S>Из практики.
Неудачная у тебя практика была

S>А, ну да. Если бы они все запускали cmd.exe, то результат был бы ошеломляющим.
S>Я просто имею некоторое представление о том, сколько ресурсов сжирает на сервере терминальная сессия.
Сессии можно делать гораздо более легковесными (сейчас страшную вещь скажу) — можно ведь и не на винде RDP сервер-то делать.

S>Даже если не считать ресурсов, пожранных приложением — те-то придется нести в более-менее любом случае; хотя в общем случае у HTTP возможностей уменьшить working set больше.
Не вижу я этих возможностей.
DOO>>Ну и, конечно, почему ты проигнорировал вариант а-ля иксы?
S>Пока что фотошоп не может работать под иксами даже локально. Не знаю почему, возможно из-за ограничений икспротокола.
Вряд ли. Скорее просто лень им.


S>Это не страшно. Эти доводы видит адобе. Хотя информации на эту тему пока очень-очень мало.
Адобе видит красивые графики от своих маркетологов

S>
S>Пользуюcь IE в чудовищных объемах ежедневно последние лет 7. Пока полет нормальный. Независимо от наличия/отсутствия антивирусов. Начинаю подозревать, что все эти разнообразные коллеги очень любят говорить "да, да, да-конечно" на всякие дурацкие вопросы.
Еще раз повторить: он зашел на сайт, опечатавшись, в результате антивирусник взругнулся, IE рухнул, а система получила свеженький вирус — т.е. даже антивирусник ничего блокировать не смог. Вот и думай. Сидит он под IE 6 — потому что ему надо постоянно пользоваться порталом, котрый кроме IE 6 ничего понимать не хочет (даже IE 7).

То, что тебя обходили всяки ANI file vurnelability и тому подобные дыры в GDI лишь показатель того, что у тебя скорее всего все нормально с Windows Update, а в конторе, скорее всего, есть IPS.

DOO>>Я сомневаюсь, что мне этот выбор оставят.
S>С таким настроением остается только употребить высокотоксичную жидкость или вступить в летальное взаимодействие со стеной. Конечно же никакого выбора не оставят. Сразу после покупки фотоаппарата присылать домой ежемесячно счета за фотопечать из назначенного в этом месяце фотоцентра.
Ну а что ерничать-то? У нас так и любят делать. На кой ляд WM 5 убрали консоль?

S>На этом мы тему закрываем, потому что мне неинтересно обсуждать элементарные вещи с человеком, которому не надо знать, чем удобный софт отличается от неудобного. Надо было с этого начать — сэкономил бы мне массу времени.
Дело твое, но что-то эти твои книги от жизни оторваны как-то...

DOO>>Ну что? Попросить мою сестру дизайнера поплеваться на это? Ты что, хочешь сказать — что это убожество и должно удовлетворить всех пользователей?
S>Я хочу сказать, что ежемесячный объем продаж этого убожества значительно превышает суммарный заработок твоей сестры за всю жизнь.
S>Я полагаю, что это от того, что кодак знает, что нужно людям, а сестра дизайнера — нет.
Что ж мы вискас-то какой-нибудь до сих пор не едим все поголовно — вот оно, творение будущего. Не надо всякую там еду готовить...



DOO>>Здесь автор делает вывод из всего вышеперечисленного, что проблема обмена рингтонов была надуманной, что и позволило в конечном итоге создать на такой мелочи целый рынок.
S>А, прошу прощения, я не понял, в чем именно проблема автора. Проблема автора — в том, что он полагает рынок рингтонов возникшим из-за проблемы обмена.
S>Нет, всё как раз наоборот. Пока был зоопарк микроформатов для рингтонов, рынка собственно не было. И сейчас, многим людям в голову не придет ставить в качестве звонка всякую муть, тем более за деньги. Тем не менее, люди платят реальные деньги за использование рингтонов. Не потому, что есть какая-то "проблема". А потому что есть потребность, которую и удовлетворяют поставщики этих рингтонов. Эту потребность невозможно было представить в 90м году. Теперь автору понятно?
А почему не сказать этим бедным людям, которые платят сначала 30 р. за получение ссылки на WAP сайт, а потом еще сколько-то за дорогущий WAP трафик, что все делается на порядок проще, что рингтон ничем не отличается от музыки в их любимом mp3 плеере, а телефон от флешки или того же плеера? Зачем городить на пустом месте рынок?

S>То есть были хорошие альтернативы, но по какой-то неизвестной причине они не заработали?
Вполне возможно.


S>>>Я тебе еще раз объясняю: у аськи основной фишкой была возможность отправлять на UIN, а не на 212.122.64.29.
DOO>>Неужели у MSN'а, AIM'а и Yahoo messanger'а было не так?

S>MSN: работы начались в 97, первый мессенджер вышел в 99м.
S>Yahoo: в 2000 вышла версия 3.0 (копирайт стоит 1998, так что возможно 1.0 была примерно в это время)
S>AIM 1.0 — в 1998.

S>ICQ: в 1996 уже вышла ICQ 1.12. Беты были доступны еще раньше.

S>Есть еще вопросы, почему гуру не рекламировали то, чего не было?
Т.е. в 99-м уже был выбор из всего вышеперечисленного. Почему же тогда по-прежнему никто не говорил ни о чем кроме аськи? Может пользователь-то все-таки привыкает, да еще и новичка своим привычкам обучает?



DOO>>Они встанут себе с разными программами и все... Если глянуть на расширения оболочки среднестатистического пользователя на моей работе — там от 30 до 50 записей...
S>Сколько у них стоит AutoPlay Extension? Сколько web publishing wizard?
А причем здесь это? 10 лет назад расширение эксплорера тоже было редкостью...



S>Во втором же ответе ты предложил:
S>"Ты хочешь странного, честно говоря. С такими замахами — зачем тебе вообще web? Делай нормальный клиент-сервер... "
S>Я вижу, что это от тяжелого непонимания простых вещей.
Каких интересно? Если тебе надо полноценное взаимодействие клиента и сервера, при этом совсем "тонкий" клиент не получается, то почему не сделать нормальное клиент-серверное приложение, без этого оверхеда HTTP и прочих web сервисов? Зачем эта вечная война с ограничениями протокола, с механизмами безопасности браузера? При том, что благой цели типа кросплатформенности здесь нет. Да и с переносимостью будут напряги — в каком интернет-кафе тебе разрешат ставить ActiveX?

Здравствуйте, AndrewJD, Вы писали:

AJD>Так сервис пак не ставит .NET, если он не стоял
Проверим. Мое ИМХО мне говорит, что ставил.

Здравствуйте, DOOM, Вы писали:
DOO>Это тоже сильно необснованный наезд.
Это кажется, что необоснованный.

S>>В целом — да. Но держать по 2000 активных пользователей одновременно вполне возможно.
DOO>Что такое 2000 пользователей для крупного web-проекта? Один фиг понадобится ферма.
И вот тут http зарулит RDP насмерть, потому что в нем балансирование нагрузки делается легко и приятно.

DOO>Ну как же — знаменитый AJAX использует XML.HTTP, а XML, если ничего не менялось, не признает бинарные данные.
XmlHttpRequest был так назван только потому, что его срочно надо было всунуть в IE, а менеджмент тогда не глядя подписывал всё с буквами Xml. Реально делается обычный HTTP реквест. Впрочем, разбор бинарных данных обычно в джаваскрипте не делают, потому выполняют подкачку картинок сразу через присваивание img src.

DOO>HTTP? Причем здесь он.
Ну и про AJAX тоже ничего не знаете.

DOO>закачка изображения на сервер, применения одного (или не одного) из фильтров, возврат изображения клиенту. ИМХО, трафик маленьким не будет.
Давайте подумаем вместе, за счет чего RDP или иксы могли бы экономить трафик по сравнению с HTTP.


DOO>Сессии можно делать гораздо более легковесными (сейчас страшную вещь скажу) — можно ведь и не на винде RDP сервер-то делать.
Один хрен сделать их весом с HTTP сессии не удастся.

S>>Даже если не считать ресурсов, пожранных приложением — те-то придется нести в более-менее любом случае; хотя в общем случае у HTTP возможностей уменьшить working set больше.
DOO>Не вижу я этих возможностей.
Я же говорю — обоснованный.

DOO>То, что тебя обходили всяки ANI file vurnelability и тому подобные дыры в GDI лишь показатель того, что у тебя скорее всего все нормально с Windows Update,
Ага. Это да. А у нас, софтных компаний, завсегда всё нормально с windows update.
DOO> а в конторе, скорее всего, есть IPS.
Насколько я знаю — нету.

DOO>>>Я сомневаюсь, что мне этот выбор оставят.
S>>С таким настроением остается только употребить высокотоксичную жидкость или вступить в летальное взаимодействие со стеной. Конечно же никакого выбора не оставят. Сразу после покупки фотоаппарата присылать домой ежемесячно счета за фотопечать из назначенного в этом месяце фотоцентра.
DOO>Ну а что ерничать-то? У нас так и любят делать. На кой ляд WM 5 убрали консоль?
Я не знаю, почему у вас так любят делать. WM 5 — это что, Windows Mobile? А зачем в ней консоль?

S>>Я полагаю, что это от того, что кодак знает, что нужно людям, а сестра дизайнера — нет.
DOO>Что ж мы вискас-то какой-нибудь до сих пор не едим все поголовно — вот оно, творение будущего. Не надо всякую там еду готовить...
Не знаю. Надо полагать, оттого что говно людям не пропиаришь. А вот календарики объективно рулят по соотношению цена/качество.

DOO>А почему не сказать этим бедным людям, которые платят сначала 30 р. за получение ссылки на WAP сайт, а потом еще сколько-то за дорогущий WAP трафик, что все делается на порядок проще, что рингтон ничем не отличается от музыки в их любимом mp3 плеере, а телефон от флешки или того же плеера? Зачем городить на пустом месте рынок?
Ты вправду думаешь, что рынок основан на незнании людей? Глупости. Невозможно скрывать от людей правду. Всё они знают. Софт для закачки mp3 в телефон существует отродясь; на мою нокию mp3 можно тупо кинуть по bluetooth с компа даже без драйверов от вендора.

Рынок рингтонов существует потому, что объективно удобнее эти рингтоны получать сразу на мобильник, чем мучиться со скачиванием нужной песни, обрезкой ее и складыванием на мобильник. Это удобство стоит тех 32 рублей, которые за него берут.

S>>Есть еще вопросы, почему гуру не рекламировали то, чего не было?
DOO>Т.е. в 99-м уже был выбор из всего вышеперечисленного. Почему же тогда по-прежнему никто не говорил ни о чем кроме аськи?
Не знаю, почему тебе никто не говорил. Я примерно в 2001 перешел на триллиан, потому что утомился держать три мессенджера одновременно.
DOO>Может пользователь-то все-таки привыкает, да еще и новичка своим привычкам обучает?
Конечно, однажды захваченный рынок тяжело отбить. Напомню, что к 98му году в аське закончились семизначные номера. Это уже более ста миллионов пользователей.
Кроме того, мессенджеры первых версий сильно от аськи отставали по функциям.

DOO>А причем здесь это?
При том, что мы обсуждаем именно его. Я же давал ссылку на статью. И существует эта техника с WinXP. Сколько ей лет?

DOO>Каких интересно? Если тебе надо полноценное взаимодействие клиента и сервера, при этом совсем "тонкий" клиент не получается, то почему не сделать нормальное клиент-серверное приложение, без этого оверхеда HTTP
Какого оверхеда HTTP? По сравнению с чем оверхед? Откуда у вас этот бред горячечный?
DOO>При том, что благой цели типа кросплатформенности здесь нет. Да и с переносимостью будут напряги — в каком интернет-кафе тебе разрешат ставить ActiveX?
В том же, в котором разрешают ставить сторонний софт. А что?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DOOM, Вы писали:
DOO>>Это тоже сильно необснованный наезд.
S>Это кажется, что необоснованный.
Ну не знаю... Надеюсь сообщество рассудит.


S>>>В целом — да. Но держать по 2000 активных пользователей одновременно вполне возможно.
DOO>>Что такое 2000 пользователей для крупного web-проекта? Один фиг понадобится ферма.
S>И вот тут http зарулит RDP насмерть, потому что в нем балансирование нагрузки делается легко и приятно.
Я уже написал почему. А еще у всего этого начинаются прикольнейшие проблемы, если переходим на https...


DOO>>Ну как же — знаменитый AJAX использует XML.HTTP, а XML, если ничего не менялось, не признает бинарные данные.
S>XmlHttpRequest был так назван только потому, что его срочно надо было всунуть в IE, а менеджмент тогда не глядя подписывал всё с буквами Xml. Реально делается обычный HTTP реквест. Впрочем, разбор бинарных данных обычно в джаваскрипте не делают, потому выполняют подкачку картинок сразу через присваивание img src.
Ну допустим... Убедил, что от base64 Adobe избавится.

DOO>>HTTP? Причем здесь он.
S>Ну и про AJAX тоже ничего не знаете.
Нет, а что тебя заставляет думать, что я про HTTP ничего не знаю?



DOO>>закачка изображения на сервер, применения одного (или не одного) из фильтров, возврат изображения клиенту. ИМХО, трафик маленьким не будет.
S>Давайте подумаем вместе, за счет чего RDP или иксы могли бы экономить трафик по сравнению с HTTP.
RDP — в случае модификации части картинки клиенту передается только модифицированная часть.
X-протокол — в данном конкретном случае экономии не даст. Можно сказать, что X-протоокол — "векторный" — он лидирует, например, при отрисовке интерфейса.
Опять же можно считать всякие накладные расходы на заголовки и т.п. Но это уже мелочи.


DOO>>Сессии можно делать гораздо более легковесными (сейчас страшную вещь скажу) — можно ведь и не на винде RDP сервер-то делать.
S>Один хрен сделать их весом с HTTP сессии не удастся.
Но добиться минимальной разницы все можно. Опять таки ты здесь web-сервер рассматриваешь исключительно как некий reverse прокси — ему запрос, он передал. Бэк энд подготовил ответ — он переслал. Конечно, при таком раскладе для него сессия легковесна. А кто займется аутентификацией, авторизацией? Кто будет обеспечивать хранение и доступ к данным сессии?

DOO>>Не вижу я этих возможностей.
S>Я же говорю — обоснованный.
Аргумент...



DOO>>Ну а что ерничать-то? У нас так и любят делать. На кой ляд WM 5 убрали консоль?
S>Я не знаю, почему у вас так любят делать. WM 5 — это что, Windows Mobile? А зачем в ней консоль?
Объясняю. Вместе с консолью убрали cmd.exe (а нафига он, раз консоли нет?). Я поставил себе на КПК pDOSBox, чтобы игрушки досовские запускать. Но теперь вынужден каждый раз запускать DOSBox, потом ручками монтировать нужный диск, потом запускать игру и все это с помощью экранной клавиатуры. Сделать скриптик я не могу cmd.exe нету.
Еще там нет блокнота — поправить произвольный текстовый файл я не могу.



S>Не знаю. Надо полагать, оттого что говно людям не пропиаришь. А вот календарики объективно рулят по соотношению цена/качество.
Да так везде можно — придумать типовое решение, которое устроить 80% народа. Остальным останется только удавиться или как ты писал:

остается только употребить высокотоксичную жидкость или вступить в летальное взаимодействие со стеной

S>Рынок рингтонов существует потому, что объективно удобнее эти рингтоны получать сразу на мобильник, чем мучиться со скачиванием нужной песни, обрезкой ее и складыванием на мобильник. Это удобство стоит тех 32 рублей, которые за него берут.
Мне это точно не понять.
Между прочим, 32 рубля это малая часть от того, что придется заплатить за WAP трафик.



DOO>>Может пользователь-то все-таки привыкает, да еще и новичка своим привычкам обучает?
S>Конечно, однажды захваченный рынок тяжело отбить. Напомню, что к 98му году в аське закончились семизначные номера. Это уже более ста миллионов пользователей.
Так-то очень грубая оценка
S>Кроме того, мессенджеры первых версий сильно от аськи отставали по функциям.
Они свою задачу основную решали? Сообщения отправляли? Ты же сам пропагандируешь применение максимально примитивных приложений, лишь бы задачу выполнить. Я тебе уже приводил пример с WMP и Winamp — по функционалу и удобству использования WMP это ужас... Но он есть "из коробки", поэтому как только WMP научился играть mp3 Winamp ставить перестали.

DOO>>А причем здесь это?
S>При том, что мы обсуждаем именно его. Я же давал ссылку на статью. И существует эта техника с WinXP. Сколько ей лет?
Дак что ты сказать-то этим хочешь? Что раз за прошедшие X лет много расширений не написали, то и дальше так будет? Я думаю, проблема лишь в том, что пока этими визардами мало кто пользуется.



DOO>>Каких интересно? Если тебе надо полноценное взаимодействие клиента и сервера, при этом совсем "тонкий" клиент не получается, то почему не сделать нормальное клиент-серверное приложение, без этого оверхеда HTTP
S>Какого оверхеда HTTP? По сравнению с чем оверхед? Откуда у вас этот бред горячечный?
Еще раз:
HTTP — stateless протокол. Не ориентированный на соединение. Протокол односторонней связи — клиент спрашивает, сервер получает. Все это приходится обходить при помощи костылей, которые этот оверхед и создают. Согласен потихоньку костыли улучшают, теперь уже посиделки в web чате не обойдутся пользователю в 20-30 Мб, но все равно web приложение до сих пор не может сравниться ни по скорости, ни по требовательности к ресурсам (в том числе к толщине канала) с нормальным клиент-сервером.
И еще раз повторю: я при этом не говорю, что web приложения это зло, я сам пользуюсь интернет банком, а не клиент банком.


DOO>>При том, что благой цели типа кросплатформенности здесь нет. Да и с переносимостью будут напряги — в каком интернет-кафе тебе разрешат ставить ActiveX?
S>В том же, в котором разрешают ставить сторонний софт. А что?
Дак зачем тогда цепляться за web со словами, что пользователю кроме браузера ничего не надо и работать он сможет с этим приложением откуда угодно?

Здравствуйте, DOOM, Вы писали:

S>>Ну и про AJAX тоже ничего не знаете.
DOO>Нет, а что тебя заставляет думать, что я про HTTP ничего не знаю?
То, что ты упоминаешь base64 и "оверхед".

S>>Давайте подумаем вместе, за счет чего RDP или иксы могли бы экономить трафик по сравнению с HTTP.
DOO>RDP — в случае модификации части картинки клиенту передается только модифицированная часть.
Посмотри google maps на тему того, как картинки ездят по HTTP. Избавляет от многих заблуждений.

DOO>X-протокол — в данном конкретном случае экономии не даст. Можно сказать, что X-протоокол — "векторный" — он лидирует, например, при отрисовке интерфейса.
При отрисовке интерфейса лидирует AJAX и XAML.

DOO>Опять же можно считать всякие накладные расходы на заголовки и т.п. Но это уже мелочи.

DOO>Но добиться минимальной разницы все можно. Опять таки ты здесь web-сервер рассматриваешь исключительно как некий reverse прокси — ему запрос, он передал. Бэк энд подготовил ответ — он переслал. Конечно, при таком раскладе для него сессия легковесна. А кто займется аутентификацией, авторизацией?
Какая разница? Кто захотим — тот и займется. Аутентификация и авторизация — далеко не самые тяжелые задачи. И в вебе они делаются на раз-два.
DOO>Кто будет обеспечивать хранение и доступ к данным сессии?
Кто захотим-тот и будет. Хочешь — будет хранение в памяти, хочешь — на диске. Веб не накладывает никаких ограничений.

S>>Я не знаю, почему у вас так любят делать. WM 5 — это что, Windows Mobile? А зачем в ней консоль?
DOO>Объясняю. Вместе с консолью убрали cmd.exe (а нафига он, раз консоли нет?). Я поставил себе на КПК pDOSBox, чтобы игрушки досовские запускать. Но теперь вынужден каждый раз запускать DOSBox, потом ручками монтировать нужный диск, потом запускать игру и все это с помощью экранной клавиатуры. Сделать скриптик я не могу cmd.exe нету.
DOO>Еще там нет блокнота — поправить произвольный текстовый файл я не могу.
а-а. Мне это как-то неблизко, я на КПК игрушки досовские не играю. А что, в pDOSBox нету command.com?

S>>Не знаю. Надо полагать, оттого что говно людям не пропиаришь. А вот календарики объективно рулят по соотношению цена/качество.
DOO>Да так везде можно — придумать типовое решение, которое устроить 80% народа. Остальным останется только удавиться или как ты писал:
Ты бы для развития кругозора съездил в Штаты, посмотрел, как там люди удавливаются. Мне б так удавливаться.
Прикинь, какое там засилье доступных сервисов!
Это я еще в японии не был — по сравнению с ней штаты, говорят, вааще каменный век.


DOO>Мне это точно не понять.
Ну, поэтому ты никогда не откроешь amazon, или youtube, или kodak.


S>>Кроме того, мессенджеры первых версий сильно от аськи отставали по функциям.
DOO>Они свою задачу основную решали? Сообщения отправляли? Ты же сам пропагандируешь применение максимально примитивных приложений, лишь бы задачу выполнить.
Нет. Кто такое сказал? Я пропагандирую применение приложений с нулевым входным порогом. Простой в использовании — не значит "примитивный".

DOO>Я тебе уже приводил пример с WMP и Winamp — по функционалу и удобству использования WMP это ужас...
Спорный момент. Винамп немногим лучше. Имхо, оба плеера недотягивают до пяти звездочек. Причем я даже не знаю, который ближе.

S>>При том, что мы обсуждаем именно его. Я же давал ссылку на статью. И существует эта техника с WinXP. Сколько ей лет?
DOO>Дак что ты сказать-то этим хочешь? Что раз за прошедшие X лет много расширений не написали, то и дальше так будет? Я думаю, проблема лишь в том, что пока этими визардами мало кто пользуется.
А-а. Ну давай подождем, когда тебе там будет 50 строк предложений фотопечати и 120 веб-провайдеров. Посмотрим, сможет ли микрософт с этим справиться. Вон — трей иконки-то усмирили, не так ли


S>>Какого оверхеда HTTP? По сравнению с чем оверхед? Откуда у вас этот бред горячечный?
DOO>Еще раз:
DOO>HTTP — stateless протокол. Не ориентированный на соединение. Протокол односторонней связи — клиент спрашивает, сервер получает. Все это приходится обходить при помощи костылей, которые этот оверхед и создают. Согласен потихоньку костыли улучшают, теперь уже посиделки в web чате не обойдутся пользователю в 20-30 Мб, но все равно web приложение до сих пор не может сравниться ни по скорости, ни по требовательности к ресурсам (в том числе к толщине канала) с нормальным клиент-сервером.
DOO>И еще раз повторю: я при этом не говорю, что web приложения это зло, я сам пользуюсь интернет банком, а не клиент банком.
Не надо мне общих слов. Я про HTTP сам могу лекции читать и семинары вести. Откуда требования к толщине канала? За счет чего клиент-сервер выиграет?
Откуда у него скорость? Какие улучшения в костылях имеются в виду? Какие костыли были до этого улучшения?
А то может я и правда чего-то важного не знаю?

DOO>Дак зачем тогда цепляться за web со словами, что пользователю кроме браузера ничего не надо и работать он сможет с этим приложением откуда угодно?
Ну ведь по факту же может. В чем проблема?

Здравствуйте, DOOM, Вы писали:

DOO>Вот здесь и иероглиф — у тебя по кнопке на "выровнять баланс цвета X" вместо двух кнопок — "выровнять баланс цвета" и "цвет".


А что обозначает, по твоему "выравнять баланс синего"?

Здравствуйте, DOOM, Вы писали:

DOO>Ну не знаю, как там у всяких сайтов фотографий, но всевозможные интерфейсы порталов, средств администрирования и т.п. поголовно используют Java для своих красивостей.

Так им же доступ к данным пользователя не нужен?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, DOOM, Вы писали:

DOO>>Ну не знаю, как там у всяких сайтов фотографий, но всевозможные интерфейсы порталов, средств администрирования и т.п. поголовно используют Java для своих красивостей.

E>Так им же доступ к данным пользователя не нужен?

И что? У Java проблемы с доступом к ФС?

Здравствуйте, Sheridan, Вы писали:

>>>> написав предварительно скрипт, штоб на все вопросы задаваемые mput отвечал y.
>> S>Эээ... что такое mput? какойто клиент? Удобнее krusader'а и тотал коммандера?
>> Ну что ж ты. Неужто не знаком с набором команд консольного ftp — клиента?
S>Я — знаком. Пользователь — нет.
S>Ты почемуто выбираеш из всего многообразия самое сложное. И преподносиш как единственно возможное.

А по-моему ты тут недооцениваешь некоторые существенные моменты. Сравнивая закачку файла по FTP и HTTP, можно увидеть следующее: FTP ориентирован на файловое хранилище на сервере. HTTP — на операцию POST, отрабатываемую обработчиком. Если выполняется POST с нагрузкой в виде файла — его отработка понятна: в заголовке есть достаточно данных идентификации, кто и что льёт (имя файла, кука для сеанса логина, etc.) Если FTP — то получается бардак. Если на сервере будет просто файловая свалка — 1) её тупо замусорят (даже просто так, без возможности попользоваться), 2) не будет понятно, как определить, когда закачка закончилась и надо этот файл обработать. Если же под видом FTP на самом деле будет нечто, которое реализует специализированную логику и по команде STOR запускает не укладку на диск в указанное место, а специальный обработчик — то тогда накой нужен такой FTP с проблемами протокола (второе соединение, мало возможности передать дополнительные данные вроде той же сеансовой куки)? На HTTP всё это реализуется значительно прямее и проще. Потому что выполняется именно действие "залить_фотку; кука=xxx имя_файла=yyy", а не странный усложнённый цикл "сначала залить, потом что-то пнуть, чтобы оно залитое переработало", да ещё и с проблемами протокола (каждый третий захочет active FTP, а будет при этом за тупым NAT).

Сейчас, кстати, даже традиционно FTP'шные файловые свалки (уж казалось бы, насколько прямая задача для FTP — файловая свалка) добавляют доступ по HTTP к тому же дереву, просто как к свалке.

Ну вот суммируя всё сказанное — и попробуем сравнить смысл того же FTP для заливки фоток и другого метода, передающего по HTTP. Мне кажется, результат сильно не в пользу FTP.:) При этом я не говорю, что ActiveX-заливальщик полезнее (хотя у него могут быть определённые преимущества типа реализации сжатия и перекодирования на клиентской стороне). В принципе и просто веб-форма с кнопкой Browse для файла — тоже весьма эффективна. Заодно можно сделать так (и обычно делается), что результат посылки POST сразу отдаёт страницу типа "зашибись, залил" или "жывотное, ездуй в Бобруйск со своей порнухой", а в случае FTP ещё непонятно, как согласовать обновление страницы заливки с закачкой...

>> S>Синклер, кто тебе сказал, что все пользователи поголовно — идиоты?
>> Да никто не сказал. Пока что я вижу как раз обратное: среди программистов процент идиотов несколько выше, чем везде.
S>Ну с этим у нас с тобой консенсус полный :) Я тоже так считаю :))

Интересно.:) Расскажите обоснование.

Здравствуйте, ralfeus, Вы писали:

R>Я набираю десятипальцевым. Переключаю раскладку Alt+Shift. Очень удобно. Большой палец сдвигается на полсантиметра. Мизинец — на два. Все остальные не шевелятся. При переключении Ctrl+Shift приходится сдвигать всю кисть, еще и гнуть нечеловечески... Согласен — переключение по CapsLock еще удобнее. Но как тогда набирать заглавными (те же константы в С)?

Кажется, я на этот вопрос не ответил (хотя в соседних письмах упоминал). Для включения реального capitals lock продолжает действовать Shift+Caps. ВОТ НАБИРАЮ ПОСЛЕ НЕГО:)

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, netch80, Вы писали:

AJD>>>Было бы вообще здорово. Жаль конечно, что MS не опубликовало в свое время спецификации.
N>>Ну да — всего-то потащить за собой винду и эмулятор x86.

AJD>Зачем?

Затем, что ActiveX обычно — бинарник. Я вот пишу сейчас из-под FreeBSD на i386. А мог бы писать на том же на альфе, если бы мы ту машинку не продали.:)

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DOOM, Вы писали:

S>>>Ну и про AJAX тоже ничего не знаете.
DOO>>Нет, а что тебя заставляет думать, что я про HTTP ничего не знаю?
S>То, что ты упоминаешь base64 и "оверхед".
Странные выводы. Про Base64 я уже кажется сказал откуда было утверждение. А оверхед — ну чтож попробуем далее по тексту разобраться, откуда он берется.

S>>>Давайте подумаем вместе, за счет чего RDP или иксы могли бы экономить трафик по сравнению с HTTP.
DOO>>RDP — в случае модификации части картинки клиенту передается только модифицированная часть.
S>Посмотри google maps на тему того, как картинки ездят по HTTP. Избавляет от многих заблуждений.
Ребята из гугл действительно сделали в этом смысле великое дело, правда, они практически одни такие.
Посмотреть реализацию google maps затруднительно, поскольку гугловцы используют свой обфускатор, но в целом, вроде, алгоритм понятен (поправь, если ошибаюсь).
Вся карта — это таблица из N ячеек, в каждой из которых живет фрагмент карты. Картинка догружается динамически, видимо, при помощи XMLHTTP — сразу вопрос, если ответ сервера сжат, кто его должен разжать? Клиентский скрипт или XMLHTTP все-таки это сам умеет?
Преимущество догрузки прямиком через XMLHTTP заключается в том, что
a) как я понял из твоих слов по XMLHTTP данные можно передать в бинарной форме
б) XMLHTTP все-таки контролируемо асинхронный, догрузка картинки, через модификацию src вызовет срабатывание скрипта onlaod, раньше чем, например, закончится текущая обработка (частая ошибка начинающих web2.0щиков).
Где остаются проблемы:
а) Число картинок — сейчас это около 15 на экран. Было бы 40-50 браузер бы начал тормозить.
б) Сжатие (тут я просто не знаю, возможно ли использование gzip'а в XMLHTTP), хотя можно использовать формат с сжатием — но в случае web-фотошопа это не прокатит.
в) preemtable — постоянный асинхронный обмен в Javascript скажется на времени реакции на действия пользователя.


DOO>>X-протокол — в данном конкретном случае экономии не даст. Можно сказать, что X-протоокол — "векторный" — он лидирует, например, при отрисовке интерфейса.
S>При отрисовке интерфейса лидирует AJAX и XAML.
Ой ли. Браузер все-таки не очень быстр. Тот же интерфейс гугла отрисовывается заметное время.
А X — это чистой воды RPC протокол.


DOO>>Но добиться минимальной разницы все можно. Опять таки ты здесь web-сервер рассматриваешь исключительно как некий reverse прокси — ему запрос, он передал. Бэк энд подготовил ответ — он переслал. Конечно, при таком раскладе для него сессия легковесна. А кто займется аутентификацией, авторизацией?

S>Аутентификация и авторизация — далеко не самые тяжелые задачи. И в вебе они делаются на раз-два.
На раз-два? Классическая схема — это БД с пользователями и form-based аутентификация — как она связана с web-сервером, который определяет возможность доступа клиента к той или иной страничке? Здесь сполшные костыли. И я не понимаю, почему такая нелюбовь у вебовцев к HTTP аутентификации — которая хотя бы может дать какую-то связь между web-сервером и приложением.


DOO>>Кто будет обеспечивать хранение и доступ к данным сессии?
S>Кто захотим-тот и будет. Хочешь — будет хранение в памяти, хочешь — на диске. Веб не накладывает никаких ограничений.
Их накладывают web-сервер и web-браузер. А еще протокол


S>а-а. Мне это как-то неблизко, я на КПК игрушки досовские не играю. А что, в pDOSBox нету command.com?
Есть. А толку? Даже набрать имя скрипта на экранке pDOSBox нетривиальная задача.


S>>>Не знаю. Надо полагать, оттого что говно людям не пропиаришь. А вот календарики объективно рулят по соотношению цена/качество.
DOO>>Да так везде можно — придумать типовое решение, которое устроить 80% народа. Остальным останется только удавиться или как ты писал:
S>Ты бы для развития кругозора съездил в Штаты, посмотрел, как там люди удавливаются. Мне б так удавливаться.
S>Прикинь, какое там засилье доступных сервисов!
S>Это я еще в японии не был — по сравнению с ней штаты, говорят, вааще каменный век.
Почему ты переводишь конкретную вещь — убогий сервис взамен полноценного, на наличие сервисов вообще?
Да мне нравится, что в Финляндии можно оплатить проезд на автобусе при помощи SMS, мне нравиться использовать интернет-магазин для покупки фотоаппаратов и т.п.
Но ты же не предлагаешь геймеру взамен его разлюбимой мега-игры, что-то простенькое в браузере или хотя бы во флеше?


DOO>>Мне это точно не понять.
S>Ну, поэтому ты никогда не откроешь amazon, или youtube, или kodak.
Кстати, youtube меня бесит полным отсутствием возможности кэширования их видео. Хотя вроде есть какие-то плагинчики к FF, которые это поддерживают.



S>Нет. Кто такое сказал? Я пропагандирую применение приложений с нулевым входным порогом. Простой в использовании — не значит "примитивный".
Но согласись, что уже освоенный инструмент обладает входным порогом заведомо ниже, чем у любого, максимально простого приложения? Про это не забыли во всех тех книгах, на которые ты ссылался? По этому поводу ведь и поговорки есть: лучшее враг хорошего, от добра добра не ищут и т.п. Я ведь тебе утверждаю, что ты ориентируешься на новичков без привычек — но не будет так всегда. Привычки будут формироваться. И будет тяга к инструменту универсальному, который позволит залить те же фотки не только на Yandex.фотки, но и на kodak.com и на fotki.com и еще куда-нибудь. Обзови этот инструмент WFTP — вот и получится, что все вернется через дцать лет на круги своя.


DOO>>Я тебе уже приводил пример с WMP и Winamp — по функционалу и удобству использования WMP это ужас...
S>Спорный момент. Винамп немногим лучше. Имхо, оба плеера недотягивают до пяти звездочек. Причем я даже не знаю, который ближе.
Однако, пока WMP mp3 не держал он был "мастдайным отстоем", а как поддержка появилась — сработала лень человека, он тут же стал терпимым.


S>Вон — трей иконки-то усмирили, не так ли
Прикольно усмирили — у меня значок, что есть нечитанная почта всегда прячется.



S>Откуда требования к толщине канала?
До XMLHTTP очень часто для передачи на сервер одного вшивенького параметра надо было сабмитить форму. В общем случае народ отсылал всю страницу целиком, потому что разбираться в премудростях взаимодействия фреймов было с одной стороны лень, с другой стороны там постоянно менялась политика из-за вылазящих проблем безопасности.
Сейчас ее более-менее решили, но все равно в общем случае передается данных больше, чем в том же FTP (хотя не спорю — сейчас это уже мелочь 1-2 %).

S>За счет чего клиент-сервер выиграет?
Со стороны клиента — не надо вести постоянную борьбу с браузером. Есть полная свобода, что хочешь, то и делаешь.
Со стороны сервера — не надо вести борьбу с web-сервером, есть полная свобода. Есть возможность инициировать обмен с клиентом (что сейчас можно предложить в вебе, кроме постоянно устаревающего контента?)
S>Откуда у него скорость?
У кого? У клиента? У него скорость, за счет того, что он может использовать что-то пошустрее Javascript, он может не придерживаться концепции гипертекстового документа, который сильно требователен к ресурсам.
S>Какие улучшения в костылях имеются в виду?
Переход от всяких hidden frame'ах к XMLHTTP
Появление cookies (реальный костыль для обеспечения хоть какого-то хранения состояния).
Появление возможности хранения данных сеанса на стороне сервера (самое, пожалуй, серьезное продвижение) — раньше можно было разве что на диске хранить (если смотреть классическое CGI приложение, без постоянно запущенного сервиса).

S>Какие костыли были до этого улучшения?
Hidden frame для асинхронного обмена
Hidden поля для хранения данных сессии на клиенте
Хранение данных сессии на жестком диске на сервере.

S>А то может я и правда чего-то важного не знаю?
Да уж наверное знаешь...

DOO>>Дак зачем тогда цепляться за web со словами, что пользователю кроме браузера ничего не надо и работать он сможет с этим приложением откуда угодно?
S>Ну ведь по факту же может. В чем проблема?
Кто тебе даст поставить ActiveX в интернет кафе?
Почему многие сайты предъявляют требования к браузерам?
Почему наличие флэш анимации это сразу требование, по сути, PiV? Про флэш игрушки вообще молчу — требования у них жуткие.
Я не думаю, что гугл, например, когда-нибудь сможет своими гугл доками заменить полноценный офис, но при этом вполне вижу нишу для данного сервиса и вполне им пользуюсь.
И не думаю, что Adobe сможет сделать полноценный web фотошоп. Сделают как тот Кодак — 18 стилей и свои заголовки.

Здравствуйте, AndrewJD, Вы писали:

N>>Плагины ставятся явно и модифицируют браузер. Но общим для всех образом, понятно для юзера и явным запросом установки.
AJD>ActiveX тоже устанавливаются явно, с явным запросом установки. Только не надо рассказывать про уязвимость которая была в IE5 и личилось автоматическими апдейтами.

Я тут рядом писал — ActiveX'ы от MS Project Server ставились на IE6 молча. И не ставились тоже молча, если хотели поставиться, а прав администратора не было. Пример месячной давности.
И никакого явного разрешения ставить ActiveX от Microsoft я не делал. Оно само так стало, по умолчанию.

N>>Я таким образом столкнулся с проблемой написания отчётов в MS Project.
AJD>Бывает. Но разве все плагины к FF или Опере прямые и безглючные?

Дело не в плагине или ActiveX как самом. Дело в том вебе и том браузере, которые совместными усилиями
1) не работали как следует безо всякого объяснения причин (причём я ж не простой юзер, если бы выдало какое-то окошко пусть даже со столбиком цифр — мне бы это дало разобраться; а оно молчало)
2) так же молча заработало при запуске из-под администратора, поставив нечто чего я не знаю и не сказав об этом ни в попапе ни в логе

Если Вы не заметили — я не против идеи того, что для каких-то специальных целей может потребоваться кусок кода на клиентской стороне в браузере. Нет, это как раз нормальная идея. Ненормально 1) использование этого подхода там, где явно можно обойтись без него, 2) чрезмерное доверие, 3) отсутствие нормальных средств логгирования и диагностики происходящего.

N>>Ну и теперь объясните мне — нахрена это разноцветное дерьмо под названием ActiveX, которое мало того что требует ненужных и безумных вещей и молча появляется в системе никого даже не предупредив, так ещё и умудряется уронить браузер? В сад, я лучше что-то полезное сделаю, чем трахаться с этим.
AJD>Кривой плагин к FF также запросто уронит браузер или сделает из него спам-бота.

Ну так и те плагины не нужны, или нужны по минимуму.

Здравствуйте, netch80, Вы писали:

N>А по-моему ты тут недооцениваешь некоторые существенные моменты. Сравнивая закачку файла по FTP и HTTP, можно увидеть следующее: FTP ориентирован на файловое хранилище на сервере. HTTP — на операцию POST, отрабатываемую обработчиком.
Ну не будем забывать, что все — это файл. То хранилище, которое так представляется пользователю и FTP-серверу на самом деле может быть совсем даже не каталогом.


N>Если выполняется POST с нагрузкой в виде файла — его отработка понятна: в заголовке есть достаточно данных идентификации, кто и что льёт (имя файла, кука для сеанса логина, etc.) Если FTP — то получается бардак. Если на сервере будет просто файловая свалка — 1) её тупо замусорят (даже просто так, без возможности попользоваться),
А ты FTP только анонимный признаешь? Каталог назначения может быть
1) Вовсе не каталог (см. выше)
2) Создаваться временно только на этот сеанс и для этого пользователя.

N>2) не будет понятно, как определить, когда закачка закончилась и надо этот файл обработать.
Вопрос как будет организованна интеграция с FTP сервером.


N>накой нужен такой FTP с проблемами протокола (второе соединение, мало возможности передать дополнительные данные вроде той же сеансовой куки)?
Здесь вся проблема опять же в том, что по природе своей web-сервер с web-приложением интегрирован, а FTP сервер — нет. Но это, в принципе, решаемо.

N>да ещё и с проблемами протокола (каждый третий захочет active FTP, а будет при этом за тупым NAT).
Ну по мнению Танненбаума NAT это вообще зло, ибо нарушает модель OSI и тормозит внедрение IPv6.
А на самом деле — уже сейчас есть продукты под названием WAF (Web application firewall) — как для защиты серверов, так и для защиты клиентов. Так что скоро у людей будут проблемы и с пользованием просто HTTP — на нем итак уже сторится целый стек сверху.


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




N>В принципе и просто веб-форма с кнопкой Browse для файла — тоже весьма эффективна. Заодно можно сделать так (и обычно делается), что результат посылки POST сразу отдаёт страницу типа "зашибись, залил" или "жывотное, ездуй в Бобруйск со своей порнухой", а в случае FTP ещё непонятно, как согласовать обновление страницы заливки с закачкой...
Да, но остается проблема массовой закачки.

Здравствуйте, DOOM, Вы писали:

N>>А по-моему ты тут недооцениваешь некоторые существенные моменты. Сравнивая закачку файла по FTP и HTTP, можно увидеть следующее: FTP ориентирован на файловое хранилище на сервере. HTTP — на операцию POST, отрабатываемую обработчиком.
DOO>Ну не будем забывать, что все — это файл.

А заодно и существенные ограничения такого подхода.

DOO> То хранилище, которое так представляется пользователю и FTP-серверу на самом деле может быть совсем даже не каталогом.

Ну вот именно что "может быть" и это нужно явно делать, нарушая при этом POLA поведения FTP-сервера. Фактически нужен специальный клиент к нему. И опять-таки — накой тогда FTP?

N>>Если выполняется POST с нагрузкой в виде файла — его отработка понятна: в заголовке есть достаточно данных идентификации, кто и что льёт (имя файла, кука для сеанса логина, etc.) Если FTP — то получается бардак. Если на сервере будет просто файловая свалка — 1) её тупо замусорят (даже просто так, без возможности попользоваться),
DOO>А ты FTP только анонимный признаешь? Каталог назначения может быть
DOO>1) Вовсе не каталог (см. выше)
DOO>2) Создаваться временно только на этот сеанс и для этого пользователя.

Ещё раз: зачем всё это городить, если HTTP команда POST сделает всё лучше, надёжнее (см. проблему NAT и active FTP) и без нарушения модели FTP?

N>>2) не будет понятно, как определить, когда закачка закончилась и надо этот файл обработать.
DOO>Вопрос как будет организованна интеграция с FTP сервером.

Вот-вот: её ещё надо явно _организовывать_.

N>>да ещё и с проблемами протокола (каждый третий захочет active FTP, а будет при этом за тупым NAT).
DOO>Ну по мнению Танненбаума NAT это вообще зло, ибо нарушает модель OSI и тормозит внедрение IPv6.

А по моему мнению, IPv6 зло, потому что 1) не решает почти ни одну проблему реально стоящую перед современным интернетом, 2) решает проблемы, которые сейчас неактуальны, 3) создаёт собственные проблемы, 4) добавляет жуткий геморрой процесса перехода. Так что — моё слово (практика, причём одновременно в программировании и администрировании) против слова теоретика и разработчика никому нафиг не нужной ОС?

N>>В принципе и просто веб-форма с кнопкой Browse для файла — тоже весьма эффективна. Заодно можно сделать так (и обычно делается), что результат посылки POST сразу отдаёт страницу типа "зашибись, залил" или "жывотное, ездуй в Бобруйск со своей порнухой", а в случае FTP ещё непонятно, как согласовать обновление страницы заливки с закачкой...
DOO>Да, но остается проблема массовой закачки. :xz:

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

Здравствуйте, netch80, Вы писали:

DOO>> То хранилище, которое так представляется пользователю и FTP-серверу на самом деле может быть совсем даже не каталогом.

N>Ну вот именно что "может быть" и это нужно явно делать, нарушая при этом POLA поведения FTP-сервера. Фактически нужен специальный клиент к нему. И опять-таки — накой тогда FTP?
Почему клиент-то специальный нужен будет?

[тут все skipped, поскольку мысль общая, а спорить по поводу необходимости или нет IPv6 совсем не охота]


N>Вот её, может быть, надо решать специальным клиентом или хотя бы кодом на клиентской стороне (точно не скажу, потому что в такие глубины не влазил). Но всё равно FTP тут только усложняет...

Да кто бы спорил! Поддерживай input type=file множественную загрузку — черт с вами, не надо никакого FTP, кроме узкоспециальных задач. И почему такой поддержки нет мне лично непонятно — input type=file неуправляем из скриптов, т.е. любые действия с ним будут носить осмысленный характер. Однако ограничение есть и его решение при помощи ActiveX меня не устраивает. В такой ситуации я предпочту FTP — это не мои проблемы как пользователя, что с ним сложнее интегрироваться.

Здравствуйте, DOOM, Вы писали:

DOO>>> То хранилище, которое так представляется пользователю и FTP-серверу на самом деле может быть совсем даже не каталогом.
N>>Ну вот именно что "может быть" и это нужно явно делать, нарушая при этом POLA поведения FTP-сервера. Фактически нужен специальный клиент к нему. И опять-таки — накой тогда FTP?
DOO>Почему клиент-то специальный нужен будет?

А что — консольный ftp годится?;)) Или IE — для _закачки_?
А вопрос того, что одни клиенты будут делать "STOR zuka/buka.jpg", а другие — "CWD zuka" + "STOR buka.jpg" и это или надо отражать в сервере, или лимитировать клиента?

N>>Вот её, может быть, надо решать специальным клиентом или хотя бы кодом на клиентской стороне (точно не скажу, потому что в такие глубины не влазил). Но всё равно FTP тут только усложняет...
DOO>Да кто бы спорил! Поддерживай input type=file множественную загрузку — черт с вами, не надо никакого FTP, кроме узкоспециальных задач. И почему такой поддержки нет мне лично непонятно — input type=file неуправляем из скриптов, т.е. любые действия с ним будут носить осмысленный характер. Однако ограничение есть и его решение при помощи ActiveX меня не устраивает. В такой ситуации я предпочту FTP — это не мои проблемы как пользователя, что с ним сложнее интегрироваться.

Ну вопрос в том, согласятся ли с тобой, что это не твои проблемы.:)

Я вот посмотрел на picasaweb.google.com — они ставят своё приложение. Уж на что, казалось бы, не-виндовые товарищи...

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, DOOM, Вы писали:

DOO>>>> То хранилище, которое так представляется пользователю и FTP-серверу на самом деле может быть совсем даже не каталогом.
N>>>Ну вот именно что "может быть" и это нужно явно делать, нарушая при этом POLA поведения FTP-сервера. Фактически нужен специальный клиент к нему. И опять-таки — накой тогда FTP?
DOO>>Почему клиент-то специальный нужен будет?

N>А что — консольный ftp годится?) Или IE — для _закачки_?
Кому какой удобнее — здесь же главная идея оставить клиенту возможность использовать привычный инструмент.

N>А вопрос того, что одни клиенты будут делать "STOR zuka/buka.jpg", а другие — "CWD zuka" + "STOR buka.jpg" и это или надо отражать в сервере, или лимитировать клиента?
Да взял и убрал каталоги вообще — заходит клиент и видит какой-то каталог . и все. Туда и льет.



N>Я вот посмотрел на picasaweb.google.com — они ставят своё приложение. Уж на что, казалось бы, не-виндовые товарищи...
Гугл поступил в этом смысле очень хитро — picasa не просто плагин для закачки, а полноценное приложение для какой-то там индексации картинок на рабочей станции. У меня знакомый поставил себе picasa раньше, чем стал пользоваться одноименным web сервисом.

Здравствуйте, netch80, Вы писали:

N>Я тут рядом писал — ActiveX'ы от MS Project Server ставились на IE6 молча. И не ставились тоже молча, если хотели поставиться, а прав администратора не было. Пример месячной давности.
N>И никакого явного разрешения ставить ActiveX от Microsoft я не делал. Оно само так стало, по умолчанию.
Дай ссылку но то сообщение, а то что-то не могу найти его
Насколько я помню ты использовал контрол который тянул другие контролы?


N>Дело не в плагине или ActiveX как самом. Дело в том вебе и том браузере, которые совместными усилиями
N>1) не работали как следует безо всякого объяснения причин (причём я ж не простой юзер, если бы выдало какое-то окошко пусть даже со столбиком цифр — мне бы это дало разобраться; а оно молчало)
В принципе, IE логирует как он загружает и запускает контрол в случае проблем.
N>2) так же молча заработало при запуске из-под администратора, поставив нечто чего я не знаю и не сказав об этом ни в попапе ни в логе

N>Если Вы не заметили — я не против идеи того, что для каких-то специальных целей может потребоваться кусок кода на клиентской стороне в браузере. Нет, это как раз нормальная идея. Ненормально 1) использование этого подхода там, где явно можно обойтись без него, 2) чрезмерное доверие, 3) отсутствие нормальных средств логгирования и диагностики происходящего.
С этим никто не спорит

AJD>>Кривой плагин к FF также запросто уронит браузер или сделает из него спам-бота.
N>Ну так и те плагины не нужны, или нужны по минимуму.
Сейчас многое из того что раньше делали на плагинах переползло на флешь

Здравствуйте, netch80, Вы писали:

N>Я вот посмотрел на picasaweb.google.com — они ставят своё приложение. Уж на что, казалось бы, не-виндовые товарищи...

Не забываем, что Гугл купил пикасу.