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

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

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

Так ты на него и отвечал прямо перед этим:) Сейчас — вверх по дереву на 4 от того сообщения, которое я вот сейчас пишу. Ссылки мне в плоском виде неудобно добывать — форум как-то их неадекватно показывает.

AJD>Насколько я помню ты использовал контрол который тянул другие контролы?

Я лично тут выступал просто как юзер: мне дали логин/пароль, я залогинился и или получил фигу, или получил результат.

AJD>Сейчас многое из того что раньше делали на плагинах переползло на флешь

А он умеет ту же массовую загрузку на сервер?

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

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

Я пока не увидел никаких обосновений overhead в HTTP. Рассуждения о XmlHttpRequest и скорости обработки полусотни картинок в браузере к HTTP имеют весьма опосредованное отношение.
На всякий случай напомню, что клиенты HTTP протокола браузером не ограничиваются.


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

DOO>Их накладывают web-сервер и web-браузер. А еще протокол
Не понимаю, о каких ограничениях идет речь. Протокол устроен максимально грамотным образом — на его основе можно сделать stateful модель, если сильно хочется выстрелить себе в ногу. Сделать же stateless X-Client невозможно.

DOO>Есть. А толку? Даже набрать имя скрипта на экранке pDOSBox нетривиальная задача.
ну тогда напиши в autoexec.bat запуск твоего скрипта.

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

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


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

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


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

S>>За счет чего клиент-сервер выиграет?
DOO>Со стороны клиента — не надо вести постоянную борьбу с браузером. Есть полная свобода, что хочешь, то и делаешь.
Демагогия. Где факты?
DOO>Со стороны сервера — не надо вести борьбу с web-сервером, есть полная свобода. Есть возможность инициировать обмен с клиентом (что сейчас можно предложить в вебе, кроме постоянно устаревающего контента?)
Как что? Высокозакэшированный контент, конечно!
S>>Откуда у него скорость?
DOO>У кого? У клиента? У него скорость, за счет того, что он может использовать что-то пошустрее Javascript, он может не придерживаться концепции гипертекстового документа, который сильно требователен к ресурсам.
S>>Какие улучшения в костылях имеются в виду?
DOO>Переход от всяких hidden frame'ах к XMLHTTP
Это что, HTTP? Это расширение функциональности IE 5.0.

DOO>Появление cookies (реальный костыль для обеспечения хоть какого-то хранения состояния).
Здрасте приехали. Cookies "появились" в HTTP/1.1. Когда он был введен?
DOO>Появление возможности хранения данных сеанса на стороне сервера (самое, пожалуй, серьезное продвижение) — раньше можно было разве что на диске хранить (если смотреть классическое CGI приложение, без постоянно запущенного сервиса).
А причем тут HTTP? CGI — не панацея. FastCGI и ISAPI тоже на рынке уже очень давно.

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

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

DOO>Почему многие сайты предъявляют требования к браузерам?
Посмотрим, что будет дальше.
DOO>Почему наличие флэш анимации это сразу требование, по сути, PiV?
А почему Doom3 это сразу DirectX9?

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

S>Для картинок GZip неактуален — поставь простой эксперимент. Всё, что можно, уже выжато png.
Для web-фотошопа будет более, чем актуален.

S>На всякий случай напомню, что клиенты HTTP протокола браузером не ограничиваются.
А сервера не ограничиваются web-серверами? А сетевой обмен не ограничивается протоколом HTTP?
Понятно, что без привязки ко всей вебовой инфраструктуре HTTP мало чем отличается от любого другого протокола. Лишние байтики на текстовые заголовки это, конечно, мелочь.



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



DOO>>И я не понимаю, почему такая нелюбовь у вебовцев к HTTP аутентификации — которая хотя бы может дать какую-то связь между web-сервером и приложением.
S>Эта нелюбовь напрямую связана с тем, что HTTP аутентификация требует всё время гонять username и password.
Это ты про которую? Про Basic?

S>Более продвинутые схемы (типа NTML) привязаны к механизму аутентификации на стороне сервера.
NTLM ты хотел сказать. NTLM, конечно, не катит — он не открытый (де юре, де факто все знают как он устроен).
Но кроме него есть как минимум стандартный DIGEST-MD5 и Kerbros.


S>Не понимаю, о каких ограничениях идет речь. Протокол устроен максимально грамотным образом — на его основе можно сделать stateful модель, если сильно хочется выстрелить себе в ногу. Сделать же stateless X-Client невозможно.
Также грамотно устроен и голый TCP, зачем протокол прикладного уровня превращать в транспорт?


DOO>>Есть. А толку? Даже набрать имя скрипта на экранке pDOSBox нетривиальная задача.
S>ну тогда напиши в autoexec.bat запуск твоего скрипта.
DOSBox autoexec не использует. В конце-концов мало ли для чего мне скрипты понадобится могут? Если WM зовет себя Windows, то я хочу увидеть там привычное поведение. Как в случае с Nokia и Maemo — Дебиан, Дебианом...


DOO>>Но ты же не предлагаешь геймеру взамен его разлюбимой мега-игры, что-то простенькое в браузере или хотя бы во флеше?
S>О, ну давай съедем с темы веб-приложений на игры. Ты, кстати, под разлюбимой мега-игрой, надо полагать, ожидаешь всенепременно FPS или RTS?
Ты себе представляешь современного подростка играющего в Lines?

S>Потому что значительно более популярные lines прекрасно чувствуют себя в браузере
Это в очередной раз подтверждает, что всему свое место. Не надо пытаться чем-то одним вытеснить все остальное.


DOO>>Кстати, youtube меня бесит полным отсутствием возможности кэширования их видео. Хотя вроде есть какие-то плагинчики к FF, которые это поддерживают.
S>А я думал он тебя бесит своим бешеным успехом вопреки невозможности кэширования.
Раньше народ прекрасно обходился embed'ами всяких QuickTime'ов. Можно было спокойно сохранить ролик. Та же докачка была. Просто надо было установить QuickTime. Такой подход до сих пор остался на многих сайтах.


S>>>Нет. Кто такое сказал? Я пропагандирую применение приложений с нулевым входным порогом. Простой в использовании — не значит "примитивный".
DOO>>Но согласись, что уже освоенный инструмент обладает входным порогом заведомо ниже, чем у любого, максимально простого приложения? Про это не забыли во всех тех книгах, на которые ты ссылался?
S>А ты почитай.
Да почитал бы с удовольствием. Было бы у меня время. Я думаю, там не на 30-40 страниц книжка.


S>WebDAV. Пока что бешеной популярности не набрал.
WebDAV требует альтернативного HTTP клиента. Не совсем webовский подход, как я понимаю.

S>Спасибо за прогноз. Можно, я отнесусь скептически к прогнозам человека, который считает ненужными сервисы, востребованные миллионами людей?
Да пожалуйста.



S>>>Откуда требования к толщине канала?
DOO>>До XMLHTTP очень часто для передачи на сервер одного вшивенького параметра надо было сабмитить форму. В общем случае народ отсылал всю страницу целиком, потому что разбираться в премудростях взаимодействия фреймов было с одной стороны лень, с другой стороны там постоянно менялась политика из-за вылазящих проблем безопасности.
S>А, ну так это совсем другая проблема. У AJAX проблема действительно есть: хорошие приложения строить трудно. То, о чем ты говоришь, это до-аяксная эпоха, веб 1.0 (по сравнению с которым ничего не изменилось — спроси Шеридана).
Замечательно. Один из постулатов вебовцев (озвученный здесь netch80) — веб приложение проще, чем, например, заморочки с интеграцией приложения и FTP-сервера. А тут выясняется, что web приложение это все-таки сложно. Очень сложно, я бы добавил. 90% сайтов в сети страдают проблемами, которые у нас наглядно демонстрируют в универе студентам в курсе web'а. Дак зачем же этот нигилизм со стороны web'а?

S>Отправка части данных и обновление части экрана — это уже, в общем случае, аякс.
Ая, если быть точным, иска-то нету

DOO>>Сейчас ее более-менее решили, но все равно в общем случае передается данных больше, чем в том же FTP (хотя не спорю — сейчас это уже мелочь 1-2 %).
S>Что именно более-менее решили, расскажи мне.
Проблемы избыточного обмена. Типа полного обновления странички ради одной строчки.


S>>>За счет чего клиент-сервер выиграет?
DOO>>Со стороны клиента — не надо вести постоянную борьбу с браузером. Есть полная свобода, что хочешь, то и делаешь.
S>Демагогия. Где факты?
Факты? Сколько ограничений в современном браузере на взаимодействие между фрэймами.
Как сделать задержку в коде на Javascript? Браузер не дает скрипту контроля над таймерами.
Пресловутый multiple upload...
Можно этот список долго продолжать.


S>Как что? Высокозакэшированный контент, конечно!
У вас в конторе, похоже, свой специфический жаргон. Даже гугл не знает, что такое "высокозакэшированный контент".


S>>>Какие улучшения в костылях имеются в виду?
DOO>>Переход от всяких hidden frame'ах к XMLHTTP
S>Это что, HTTP? Это расширение функциональности IE 5.0.
Все же сложно рассуждать про HTTP как про сферический конь в вакууме. Если уж речь про web, то это и web-клиент и web-сервер и протокол обмена.

DOO>>Появление cookies (реальный костыль для обеспечения хоть какого-то хранения состояния).
S>Здрасте приехали. Cookies "появились" в HTTP/1.1. Когда он был введен?
Но не сразу. Я в курсе, то cookies старше меня как пользователя сети интернет.

S>А причем тут HTTP? CGI — не панацея. FastCGI и ISAPI тоже на рынке уже очень давно.
Борьба со stateless.




S>>>Какие костыли были до этого улучшения?
DOO>>Hidden frame для асинхронного обмена
DOO>>Hidden поля для хранения данных сессии на клиенте
DOO>>Хранение данных сессии на жестком диске на сервере.
S>А, то есть мы говорим о технологиях образца 1991 года.
В том же 91-м уже можно было построить нормального клиент-сервера без таких проблем.
Вопрос: на кой ляд 15 лет надо было двигаться этим сложным путем?




DOO>>Почему наличие флэш анимации это сразу требование, по сути, PiV?
S>А почему Doom3 это сразу DirectX9?
А Doom3 это вообще позор ID Software
Им бы у Valve поучиться движки делать...

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

DOO>>И я не понимаю, почему такая нелюбовь у вебовцев к HTTP аутентификации — которая хотя бы может дать какую-то связь между web-сервером и приложением.
S>Эта нелюбовь напрямую связана с тем, что HTTP аутентификация требует всё время гонять username и password. Более продвинутые схемы (типа NTML) привязаны к механизму аутентификации на стороне сервера.

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

И чем это NTLM более продвинута?

DOO>>Их накладывают web-сервер и web-браузер. А еще протокол :))
S>Не понимаю, о каких ограничениях идет речь. Протокол устроен максимально грамотным образом — на его основе можно сделать stateful модель, если сильно хочется выстрелить себе в ногу. Сделать же stateless X-Client невозможно.

Почему stateful — стрельба в ногу?

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

youtube, кстати, ещё можно нормально скачать. Многие другие — нет.

DOO>>По этому поводу ведь и поговорки есть: лучшее враг хорошего, от добра добра не ищут и т.п.
S>Про поговорки — см. ЖЖ Лукьяненко.

Ты бы ещё к лешему послал.;(

DOO>>Обзови этот инструмент WFTP — вот и получится, что все вернется через дцать лет на круги своя.
S>WebDAV. Пока что бешеной популярности не набрал.
S>Спасибо за прогноз. Можно, я отнесусь скептически к прогнозам человека, который считает ненужными сервисы, востребованные миллионами людей?

А где миллионное использование WebDAV? Мне уже просто интересно, а то я со своими демонами мира не вижу.:)

DOO>>Появление cookies (реальный костыль для обеспечения хоть какого-то хранения состояния).
S>Здрасте приехали. Cookies "появились" в HTTP/1.1. Когда он был введен?

Cookies появились _de facto_ ещё в реализациях со "средними" версиями HTTP/1.0. Стандарт же (HTTP/1.1) безнадёжно запоздал, хотя наконец-то оформил что-то общее.

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

N>Ну ладно, ты куки не считаешь аутентификацией, но кто тебе мешает узнать про digest? В котором по крайней мере пароль открыто не бегает, так что оснований для нелюбви должно быть поменьше.
N>И чем это NTLM более продвинута?
Она примерно работает как и digest.

S>>Не понимаю, о каких ограничениях идет речь. Протокол устроен максимально грамотным образом — на его основе можно сделать stateful модель, если сильно хочется выстрелить себе в ногу. Сделать же stateless X-Client невозможно.
N>Почему stateful — стрельба в ногу?
Плохо масштабируется.

S>>Спасибо за прогноз. Можно, я отнесусь скептически к прогнозам человека, который считает ненужными сервисы, востребованные миллионами людей?
N>А где миллионное использование WebDAV? Мне уже просто интересно, а то я со своими демонами мира не вижу.
В принципе, на миллионное использование WebDAVа должно набраться. Скажем, его используют "Web Folders" в Windows.

Ну и Subversion через DAV не стоит забывать

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

C>В принципе, на миллионное использование WebDAVа должно набраться. Скажем, его используют "Web Folders" в Windows.
Ни разу не видел использование Web Folders в винде.
К тому же, доступ по WebDAV эмулирует эксплорер, но это не он — контекстное меню уже не столь богато.

C>Ну и Subversion через DAV не стоит забывать
Ох уж этот Subversion с DAV'ом... Сколько я времени убил, но так и не заставил его работать...

DOOM wrote:
> C>В принципе, на миллионное использование WebDAVа должно набраться.
> Скажем, его используют "Web Folders" в Windows.
> Ни разу не видел использование Web Folders в винде.
> К тому же, доступ по WebDAV эмулирует эксплорер, но это не он —
> контекстное меню уже не столь богато.
Я своих заказчиков к нему приучил. Совместно с SVN autoversioning'ом —
вообще супер.

> C>Ну и Subversion через DAV не стоит забывать
> Ох уж этот Subversion с DAV'ом... Сколько я времени убил, но так и не
> заставил его работать...
Во всех новых дистрибутивов работает без проблем.

Хотя я в своем время (когда Subversion еще была в версии 0.26) сам все
без проблем собирал.

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

C>DOOM wrote:
>> C>В принципе, на миллионное использование WebDAVа должно набраться.
>> Скажем, его используют "Web Folders" в Windows.
>> Ни разу не видел использование Web Folders в винде.
>> К тому же, доступ по WebDAV эмулирует эксплорер, но это не он —
>> контекстное меню уже не столь богато.
C>Я своих заказчиков к нему приучил. Совместно с SVN autoversioning'ом —
C>вообще супер.
А заем DAV клиент? Черепашка (TortoiseSVN в смысле) и вперед...


>> C>Ну и Subversion через DAV не стоит забывать
>> Ох уж этот Subversion с DAV'ом... Сколько я времени убил, но так и не
>> заставил его работать...
C>Во всех новых дистрибутивов работает без проблем.
Короче, если ты в Debian etch сможешь настроить DAV_SVN, который будет использовать SVNParentPath и при этом нормально работать с русскими именами репозиториев я тебе... ну не то, чтобы памятник поставлю... и даже, наверное, пиво-то будет проблематично поставить... но вот глубочайший респект и соответствующее кол-во баллов точно обещаю.

DOOM wrote:
> C>Я своих заказчиков к нему приучил. Совместно с SVN autoversioning'ом —
> C>вообще супер.
> А заем DAV клиент? Черепашка (TortoiseSVN в смысле) и вперед...
Черепашку надо еще ставить, учить людей делать checkout и т.п. А тут они
просто прямо в Word'е открывают URL и работают.

> C>Во всех новых дистрибутивов работает без проблем.
> Короче, если ты в Debian etch сможешь настроить DAV_SVN, который будет
> использовать SVNParentPath и при этом нормально работать с русскими
> именами репозиториев я тебе... ну не то, чтобы памятник поставлю... и
> даже, наверное, пиво-то будет проблематично поставить... но вот
> глубочайший респект и соответствующее кол-во баллов точно обещаю.
SVNParentPath я не пробовал. А какие проблемы с именами репзиториев?

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

C>DOOM wrote:
>> C>Я своих заказчиков к нему приучил. Совместно с SVN autoversioning'ом —
>> C>вообще супер.
>> А заем DAV клиент? Черепашка (TortoiseSVN в смысле) и вперед...
C>Черепашку надо еще ставить, учить людей делать checkout и т.п.
Зато у черепашки самое нормальное сравнение вордовских документов...


C>SVNParentPath я не пробовал. А какие проблемы с именами репзиториев?
Очень просто. Когда у тебя основной URL указывает на ParentPath, а репозиторий имеет русское имя, то результирующий URL имеет вид: http://svn.example.com/%2A%3E..., а потом эти %xx поступают прямо в SVN, на что он резонно замечает, no such name... Короче, кто-то забывает перегнать закодированный URL обратно... В svn-users мне сказали, что в последних версиях Apache, mod_dav_svn и subversion под мак осью все гут... Пытался пересобрать этот модуль под Дебианом — счастья не стало.

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


KV>Во-вторых — не использовать IE вообще — крайне затруднительно, и от пользователя не зависит в общем случае.

Фигассе. Это почему? Не использую, и не жалею. Опера наше все. И с трубы в том числе.

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

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


I>>Ну во первых, если сравнивать IE и FF по функциональности, то можешь спросить у разарбов — большинство юзает FF изза удобности плагов, изза того, что можно "настроить под себя".
S>Разарбы — это кто? Если ты про web developer, то я тебе открою тайну: это как раз мы. И используем мы ровно IE в качестве основного браузера, просто потому, что он занимает большинство рынка. Настраивать систему "под себя" разработчик права не имеет. Кого интересует, что FF лучше поддерживает CSS? Нас интересует, чтобы пользователь увидел то, что задумал разработчик. Кого интересует отладчик скриптов FF, если бага в скрипте проявляется в IE?
S>Добро пожаловать в мир разработки для людей.

В этом ключе я понимаю веб-девелоперов в их мечте, чтобы остался один браузер(пусть это будет даже глючный IE, но один).
Но как пользователь я люблю Оперу, и пока переходить на другой продукт не хочу. От веб-девелоперов хочется хотя-бы отсутствие сугубо browser-specific features, а также всяких "этот сайт требует для просмотра браузер ХХХ".

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

C>>Черепашку надо еще ставить, учить людей делать checkout и т.п.
DOO>Зато у черепашки самое нормальное сравнение вордовских документов...
Учитывая интеллектуальный уровень некоторых консультантов, которые правят документы, — им это не поможет.

DOO>Очень просто. Когда у тебя основной URL указывает на ParentPath, а репозиторий имеет русское имя, то результирующий URL имеет вид: http://svn.example.com/%2A%3E..., а потом эти %xx поступают прямо в SVN, на что он резонно замечает, no such name... Короче, кто-то забывает перегнать закодированный URL обратно... В svn-users мне сказали, что в последних версиях Apache, mod_dav_svn и subversion под мак осью все гут... Пытался пересобрать этот модуль под Дебианом — счастья не стало.
Можно еще попробовать URL rewriting'ом его долбануть.

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

C>Можно еще попробовать URL rewriting'ом его долбануть.

Подробнее можно? Извращения с mod_rewrite'ом или какой-то более узконаправленный инструмент?
Так-то понятно, что это будет костыль, но все же... Просто разбираться, как это можно сделать mod_rewrite'ом у меня времени не было...

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

C>>Можно еще попробовать URL rewriting'ом его долбануть.
DOO>Подробнее можно? Извращения с mod_rewrite'ом или какой-то более узконаправленный инструмент?
Именно mod_rewrite'ом.

DOO>Так-то понятно, что это будет костыль, но все же... Просто разбираться, как это можно сделать mod_rewrite'ом у меня времени не было...
У меня с ним был опыт боев, попробую на досуге сделать.

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

S>А почему Doom3 это сразу DirectX9?

Движки от ID в Windows-варианте используют DirectInput и DirectSound. Графика выводится средствами OpenGL