Ну, скажем так, я нигде не писал о революционном развитии. Поскольку версия протокола передаётся в заголовке запроса, сервер может параллельно работать и с 1.1, и с любой другой новой версией. Причём, код для 1.1 уже есть, его даже трогать не надо будет.
По вопросу же возможного развития, вероятно, наши мнения не совпадают. Тут, думаю, время рассудит.
Мне кажется, переписывать имеет смысл HTTP плюс DOM. HTTP, если я правильно помню, это верхний уровень, приложений. DOM скорее всего в OSI просто не входит.
По поводу каждой второй строчки — вероятно, так же, как и сейчас. Впрочем, могут быть интересные оптимизированные решения. Надо отдельно подумать.
> Что 10 лет назад, что сейчас — tcp-ip работает недостаточно надёжно чтобы надеяться
> что соединение будет долго открыто, и нет оснований считать, что web сервер сможет
> долго поддерживать соединение (keepalive на нагруженных серверах уже работает
> плохо).
Я бы сказал, что надёжность соединения выросла на порядок. Хотя сразу вспоминается «не единого разрыва», но тем не менее, 10 лет назад большинство подключений были по модему, сейчас по АДСЛ и оптике.
Ну и речь не о keep-alive в смысле физическом, а скорее, в логическом. Если соединение утеряно, оно должно быть автоматически восстановлено, условно говоря, с того же самого места.
> Синтаксис Ваш показывает, что Вы хотите получить результат, как будто пишете
> синхронную (последовательно выполняющуюся) программу, но этого же нет и не будет в
> обозримом будущем. Если Вы напишете два подобных оператора, в каком порядке они
> выполнятся?
Синтаксис мой показывает желание продемонстрировать идею, больше ничего.
Я думаю, что назрела необходимость в новом протоколе, более высокоуровневом. Если что-то подобное появится, то, скажем, 80-90% кода на JavaScript будет реализовано в рамках протокола создателяеми браузеров/вебсерверов.
И 20 строчек кода на js превратятся в одну. А 400 в 20. Тогда вопрос быстродействия снимается.
Вот в первой половине своего поста Вы как раз описываете проблемы HTTP. Он создан для статического контента, а веб уже лет 10 как динамический. Ну ладно, 8.
Что считать контентом? Вот вопрос.
По поводу jQuery — они закрыли вопрос использования, но не вопрос быстродействия. Всё равно «внутри» исполняется 10-20-30 медленных JavaScript-инструкций. О чём, собственно, и наша тема.
Писать так, как я написал, не надо. У меня указано специально — «синтаксис очень условный». Если Вам интересно, как это может быть, давайте обсуждать, это интересно. Если Вы считаете, что действительно, менять ничего не стоит, или стоит, но не в протоколе/DOM/ещё чём-то, давайте покрутим Ваши идеи.
Если Вы под сессиями понимаете куки, то я не назову это поддержкой. Чтобы обосновать, напомню историю 5-тилетней давности. В PHP, если куки включены, сессия делается посредством них, если же нет, посредством query-переменной, которая по умолчанию называется PHPSESSID. Думаю, это всё Вам известно, но пишу, чтобы исключить возможное недопонимание.
Механизм прекрасно работает в браузерах. Но как только речь заходит о поисковых роботах, возникает проблема. Они, ествественно, куки не поддерживают, поэтому каждый раз, заходя на страницу, получают новое значение PHPSESSID. URL разные, следовательно, и страницы тоже считаются разными. И на этом захлёбываются инструменты анализа логов.
Насколько я знаю, как-то эту проблему разрешили, то ли на уровне поисковых роботов, то ли на уровне инструментария. А может быть, и нет. Тем не менее, я помню все эти бодания.
И, если посмотреть на проблему пристально, выяснится, что она вытекает из особенностей HTTP. Вот если ввести понятие «сессия», то проблемы бы не было.
А event'ы — это событие. Мы хотим, чтобы при нажатии на кнопку BUTTON в SELECT подгрузился бы какой-нибудь список. Как это делается сейчас? AJAX, XHttpRequest, ну, наверное, какой-нибудь фреймворк, который скрывает 10-20-30 строчек кода. На более высоком уровне можно было бы написать: у BUTTON есть серверный обработчик события onserverclick. Тогда при нажатии на кнопку браузер сам шлёт запрос серверу, тот стандартным способом собирает данные и отправляет их.
Ну а у нас в обработчике можно написать (синтаксис очень условный):
document.all['my_select'].items = server.response;
Вместо js используется быстрый код на Си++ (соответствующая поддержка нового стандарта в браузере и сервере). И тогда уже не нужно думать, как ускорить js-код, всё работает. Да и сам код проще, и миллионы вебмастеров вздыхают с облегчением.
Ещё раз повторю, это некая идеальная картинка. Лично мне кажется, что дальнейшее развитие веба возможно и по такому варианту. Но как оно будет, не знаю. И не настаиваю.
А! Подозреваю, что дело опять в том, что письменный текст не передаёт интонации. Что касается первого моего комментария, то там высокопарности не подразумевалось. Хочется поозорничать и насолить мейл. ру.
Вот во втором да, но там скорее даже не высокопарность, а личная позиция, высказанная действительно серьёзно. Ну, если она кажется высокопарной, даже не знаю, что сказать. Наверное, действительно, присутствует такое.
Что-то у нас по кругу дискуссия получается. «У меня шарики красные» — «А у меня зелёные» — «Да, но у меня то красные» — «А я говорю, у меня зелёные». Давайте попробуем с другого конца зайти.
Вы утверждаете, что протокол развивать не надо, достаточно заплаток? Или сам термин «заплатки» кажется Вам притянутым за уши, и с протоколом вообще всё нормально? Или Вы считаете, что протокол менять надо, но не прямо сейчас? Или Вы не за резкую смену, а постепенную, чтобы не терять наработки?
Что именно в моём тезисе кажется Вам неправильным?
Обидны мне слова Ваши. Я, собственно, и написал для того, чтобы знающие люди подсказали, как можно переслать. Может быть, кто-то её знает лично, или по переписке, или знает её ЖЖ.
Я на mail.ru сейчас просто не зарегистрирован, и даже не очень представляю, как её искать. Если надо будет зарегистрироваться, зарегистрируюсь.
Мне аналогия кажется несколько нелогичной. Человек это человек, а технологии это технологии.
Только на моей памяти было несколько технологических прорывов. Я ещё помню время, когда мы пользовались дискетками на 5 дюймов и 360Кб ОЗУ. Я помню время, когда писали под ДОС.
А сейчас у нас гигабайтные флешки и event-oriented windows-based программирование.
Ну и в данном конкретном случае, я нисколько не умаляю тех самых гигантов. Тем не менее, Ньютон Нюьтоном, а Эйнштейн Эйнштейном.
А что делать? Сейчас ситуация выглядит так: на каждое требование индустрии изобретается новая заплатка. Сначала CGI, затем куки, затем JS и DOM, затем XHTTPRequest.
И всё это механизмы низкоуровневые.
Впрочем, о предложениях с моей стороны говорить не стоит. Я лишь замечаю определённый тупик в развитии, но не готов предсказать, когда и как ситуация изменится.
Java была хорошим решением, позволяла писать высокоуровневые производительные программы. К сожалению, Sun несколько напортачила с библиотеками, затем Microsoft насолила. И это очень печально.
Я предлагаю (ну, как предлагаю, скорее мечтаю), чтобы появился протокол, уровень которого соответствует уровню существующих задач.
Чтобы сессии поддерживались не через низкоуровневые куки. Чтобы события от сервера клиенту и наоборот передавались стандартным высокоуровневым способом. Чтобы элементы управления соответствовали современным стандартам.
Иначе получается так, как получается: любая задача требует, ну, пусть не затрат на написание (в условиях, когда столько фреймворков появилось), но всё-равно выполнения многих строк js-кода.
Ну, если серьёзно, то любой взрослый человек знает, что мир несправедлив. Работают одни, а повышают других. Женщины любят почему-то подонков и алкоголиков. А мужчины по неизвестной причине — не хороших матерей, и даже не хороших любовниц, а красивых кукол. Ну и вообще — «вкус у смерти безупречен, в отборе лучших среди нас».
Единственный способ сделать мир справедливее, это быть справедливым самому. Я говорю не об общественной установке, а о личном выборе.
В данном конкретном случае — девушка заслужила приз. Ну, пусть этот приз будет, не смотря на козни мейл. ру. В общем, если возможность есть, я бы поучаствовал.
По вопросу же возможного развития, вероятно, наши мнения не совпадают. Тут, думаю, время рассудит.
Мне кажется, переписывать имеет смысл HTTP плюс DOM. HTTP, если я правильно помню, это верхний уровень, приложений. DOM скорее всего в OSI просто не входит.
По поводу каждой второй строчки — вероятно, так же, как и сейчас. Впрочем, могут быть интересные оптимизированные решения. Надо отдельно подумать.
> что соединение будет долго открыто, и нет оснований считать, что web сервер сможет
> долго поддерживать соединение (keepalive на нагруженных серверах уже работает
> плохо).
Я бы сказал, что надёжность соединения выросла на порядок. Хотя сразу вспоминается «не единого разрыва», но тем не менее, 10 лет назад большинство подключений были по модему, сейчас по АДСЛ и оптике.
Ну и речь не о keep-alive в смысле физическом, а скорее, в логическом. Если соединение утеряно, оно должно быть автоматически восстановлено, условно говоря, с того же самого места.
> Синтаксис Ваш показывает, что Вы хотите получить результат, как будто пишете
> синхронную (последовательно выполняющуюся) программу, но этого же нет и не будет в
> обозримом будущем. Если Вы напишете два подобных оператора, в каком порядке они
> выполнятся?
Синтаксис мой показывает желание продемонстрировать идею, больше ничего.
Я думаю, что назрела необходимость в новом протоколе, более высокоуровневом. Если что-то подобное появится, то, скажем, 80-90% кода на JavaScript будет реализовано в рамках протокола создателяеми браузеров/вебсерверов.
И 20 строчек кода на js превратятся в одну. А 400 в 20. Тогда вопрос быстродействия снимается.
Что считать контентом? Вот вопрос.
По поводу jQuery — они закрыли вопрос использования, но не вопрос быстродействия. Всё равно «внутри» исполняется 10-20-30 медленных JavaScript-инструкций. О чём, собственно, и наша тема.
Писать так, как я написал, не надо. У меня указано специально — «синтаксис очень условный». Если Вам интересно, как это может быть, давайте обсуждать, это интересно. Если Вы считаете, что действительно, менять ничего не стоит, или стоит, но не в протоколе/DOM/ещё чём-то, давайте покрутим Ваши идеи.
Механизм прекрасно работает в браузерах. Но как только речь заходит о поисковых роботах, возникает проблема. Они, ествественно, куки не поддерживают, поэтому каждый раз, заходя на страницу, получают новое значение PHPSESSID. URL разные, следовательно, и страницы тоже считаются разными. И на этом захлёбываются инструменты анализа логов.
Насколько я знаю, как-то эту проблему разрешили, то ли на уровне поисковых роботов, то ли на уровне инструментария. А может быть, и нет. Тем не менее, я помню все эти бодания.
И, если посмотреть на проблему пристально, выяснится, что она вытекает из особенностей HTTP. Вот если ввести понятие «сессия», то проблемы бы не было.
А event'ы — это событие. Мы хотим, чтобы при нажатии на кнопку BUTTON в SELECT подгрузился бы какой-нибудь список. Как это делается сейчас? AJAX, XHttpRequest, ну, наверное, какой-нибудь фреймворк, который скрывает 10-20-30 строчек кода. На более высоком уровне можно было бы написать: у BUTTON есть серверный обработчик события onserverclick. Тогда при нажатии на кнопку браузер сам шлёт запрос серверу, тот стандартным способом собирает данные и отправляет их.
Ну а у нас в обработчике можно написать (синтаксис очень условный):
document.all['my_select'].items = server.response;
Вместо js используется быстрый код на Си++ (соответствующая поддержка нового стандарта в браузере и сервере). И тогда уже не нужно думать, как ускорить js-код, всё работает. Да и сам код проще, и миллионы вебмастеров вздыхают с облегчением.
Ещё раз повторю, это некая идеальная картинка. Лично мне кажется, что дальнейшее развитие веба возможно и по такому варианту. Но как оно будет, не знаю. И не настаиваю.
Вот во втором да, но там скорее даже не высокопарность, а личная позиция, высказанная действительно серьёзно. Ну, если она кажется высокопарной, даже не знаю, что сказать. Наверное, действительно, присутствует такое.
Вы утверждаете, что протокол развивать не надо, достаточно заплаток? Или сам термин «заплатки» кажется Вам притянутым за уши, и с протоколом вообще всё нормально? Или Вы считаете, что протокол менять надо, но не прямо сейчас? Или Вы не за резкую смену, а постепенную, чтобы не терять наработки?
Что именно в моём тезисе кажется Вам неправильным?
Я на mail.ru сейчас просто не зарегистрирован, и даже не очень представляю, как её искать. Если надо будет зарегистрироваться, зарегистрируюсь.
Только на моей памяти было несколько технологических прорывов. Я ещё помню время, когда мы пользовались дискетками на 5 дюймов и 360Кб ОЗУ. Я помню время, когда писали под ДОС.
А сейчас у нас гигабайтные флешки и event-oriented windows-based программирование.
Ну и в данном конкретном случае, я нисколько не умаляю тех самых гигантов. Тем не менее, Ньютон Нюьтоном, а Эйнштейн Эйнштейном.
И всё это механизмы низкоуровневые.
Впрочем, о предложениях с моей стороны говорить не стоит. Я лишь замечаю определённый тупик в развитии, но не готов предсказать, когда и как ситуация изменится.
Java была хорошим решением, позволяла писать высокоуровневые производительные программы. К сожалению, Sun несколько напортачила с библиотеками, затем Microsoft насолила. И это очень печально.
Чтобы сессии поддерживались не через низкоуровневые куки. Чтобы события от сервера клиенту и наоборот передавались стандартным высокоуровневым способом. Чтобы элементы управления соответствовали современным стандартам.
Иначе получается так, как получается: любая задача требует, ну, пусть не затрат на написание (в условиях, когда столько фреймворков появилось), но всё-равно выполнения многих строк js-кода.
Единственный способ сделать мир справедливее, это быть справедливым самому. Я говорю не об общественной установке, а о личном выборе.
В данном конкретном случае — девушка заслужила приз. Ну, пусть этот приз будет, не смотря на козни мейл. ру. В общем, если возможность есть, я бы поучаствовал.
Один парадокс: как только сотрудник становится начальником, у него возникает та же самая проблема. :)