Before we get going, here are some alternate titles for this post, just to give you an idea of what I'm trying to get at before I actually, you know, get at it:
* You're probably wondering why Yahoo bought Konfabulator
* An update on Google Browser, GooOS and Google Desktop
* A platform that everyone can stand on and why Apple, Microsoft, and, yes, even Google will have to change their ways to be a part of it
* The next killer app: desktop Web servers
* Does the Mozilla Foundation have the vision to make Firefox the most important piece of software of this decade?
* Web 3.0
* Finally, the end of Microsoft's operating system dominance
Не понятно, причем здесь OS? OS (операционная система) -- это прослойка между железом и прикладными программами. Здесь же речь идет о новых принципах создания приложений. Но эти принципы, имхо, совершенно никак не повлияют на роль и значимость именно операционных систем (Windows, MacOS, Linux, *BSD, ...). Так что один из возможных заголовков: "Finally, the end of Microsoft's operating system dominance" вообще к содержанию статьи, имхо, не имеет никакого отношения.
Имхо, сложность создания приложения, которое может работать как на стороне Google/Yahoo/Apple, так и локально на стороне клиента, ну оОочень велика. На стороне контент-провайдера может быть использован специализированный сервер приложений, заточенный под конкретную задачу. Может быть использована специализированная же БД для поддержки фантастически большого объема данных. И прикладной код того же Gmail может быть сильно завязан на такую архитектуру. Для того, чтобы сделать версию Gmail, способную работать offline, имхо, придется делать отдельную версию приложения Gmail, которая сможет работать на машине рядового пользователя. Ведь мало поставить пользователю локальный web-сервер. Туда нужно будет включить еще и сервер приложений, и БД. Вряд ли на машине клиента можно будет использовать то же ПО, которое работает на серверах контент-провайдера. Т.е., в чистом виде существующий код Web-приложения не получится использовать у клиента. Нужно будет создавать адаптированную версию. А будет ли у этой версии какие-то преимущества от того, что ее GUI будет работать через браузер?
Кроме того, мне интересно, какое ПО, кроме Web-сервера, потребуется устанавливать клиенту. Сервер приложений? СУБД? И это только для одного приложения. А если таких приложений несколько? Как они будут дружить между собой?
У Web-приложений есть очень серьезное преимущество по сравнению с desktop-приложениями: кода приложения нет у клиента. Это позволяет контент-провайдеру обновлять свое ПО без необходимости обновления чего-либо у клиента. Например, в интерфейсе Yahoo Mail! каждые несколько месяцев что-то изменяется. Но для использования этих изменений мне не нужно ничего обновлять у себя. Что еще более важно, контент-провайдер может менять представление данных (например, схему БД) тогда, когда ему это заблагорасудится. А представим теперь, что у миллионов пользователей Yahoo Mail! установлены локальные копии ПО. Как тогда заставить всех клиентов обновлять установленные у себя версии Yahoo Mail? Ведь клиент оплачивает трафик и мне бы не понравилось оплачивать закачку нескольких мегабайт нового кода только из-за того, что разработчикам Yahoo захотелось добавить несколько полей в таблицы локальной почтовой БД.
А если не заставлять клиентов обновлять свое ПО, то Yahoo столкнется с необходимостью поддержки нескольких поколений своего клиентского ПО. Что со временем станет для Yahoo серьезной головной болью. Да и другие технические проблемы так же могут стать болезненными занозами. Например, изменяется схема данных в локальной БД. Клиент закачал необходимые заплатки и его ПО начало обновление БД. Здесь происходит какой-то сбой. Допускать потерю данных у клиента нельзя. Значит процедура update должна быть надежной, отлаженной (что при современной глючности софта уже выглядит смешно) и иметь в своем распоряжении все необходимые ресурсы. А что, если на моем ноутбуке нет свободных 3Gb места для создания резервной копии БД пока моя локальная копия Yahoo Mail будет проводить собственный update?
И вот интересно, Yahoo это все нужно?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
thnx
E>
E>Не понятно, причем здесь OS? OS (операционная система) -- это прослойка между железом и прикладными программами. Здесь же речь идет о новых принципах создания приложений. Но эти принципы, имхо, совершенно никак не повлияют на роль и значимость именно операционных систем (Windows, MacOS, Linux, *BSD, ...). Так что один из возможных заголовков: "Finally, the end of Microsoft's operating system dominance" вообще к содержанию статьи, имхо, не имеет никакого отношения.
Ну, по большому счету, то, что имел в виду Коттке — это скорее Window Manager (windows explorer, linux xwindow-kde-gnome, macOS — все что там поверх BSD). И если мы (к примеру) заменяем такую сложную, противоречивую, быстроустаревающую систему на один-единственный "супербраузер", то для среднего пользователя то что там поднизом лежит (собственно, операционная система) — вообще нафик неважно. Вот здесь-то и лежит корень потери различий между ОС — если все эти веб-приложения в браузере выглядят одинаково, то какая нафик разница, какая у нас там NTFS/ext3fs/ReiserFS...
E>
E>Имхо, сложность создания приложения, которое может работать как на стороне Google/Yahoo/Apple, так и локально на стороне клиента, ну оОочень велика. На стороне контент-провайдера может быть использован специализированный сервер приложений, заточенный под конкретную задачу. Может быть использована специализированная же БД для поддержки фантастически большого объема данных.
[...]
Тут со всем практически согласен. Единственное — я имел в виду не совсем stand-alone приложение, а смарт-клиента (как Янус для RSDNa). Перспективы сегодня у таки программ — весьма.
E>
E>У Web-приложений есть очень серьезное преимущество по сравнению с desktop-приложениями: кода приложения нет у клиента. Это позволяет контент-провайдеру обновлять свое ПО без необходимости обновления чего-либо у клиента.
ВО!!! А вот тут спасибо — об этом я как-то не сильно задумывался. Вопросы это, конечно, при необходимости, решаемые, но таки весьма проблемные.
Здравствуйте, Зверёк Харьковский, Вы писали:
E>>Не понятно, причем здесь OS? OS (операционная система) -- это прослойка между железом и прикладными программами. Здесь же речь идет о новых принципах создания приложений. Но эти принципы, имхо, совершенно никак не повлияют на роль и значимость именно операционных систем (Windows, MacOS, Linux, *BSD, ...). Так что один из возможных заголовков: "Finally, the end of Microsoft's operating system dominance" вообще к содержанию статьи, имхо, не имеет никакого отношения.
ЗХ>Ну, по большому счету, то, что имел в виду Коттке — это скорее Window Manager (windows explorer, linux xwindow-kde-gnome, macOS — все что там поверх BSD). И если мы (к примеру) заменяем такую сложную, противоречивую, быстроустаревающую систему на один-единственный "супербраузер", то для среднего пользователя то что там поднизом лежит (собственно, операционная система) — вообще нафик неважно. Вот здесь-то и лежит корень потери различий между ОС — если все эти веб-приложения в браузере выглядят одинаково, то какая нафик разница, какая у нас там NTFS/ext3fs/ReiserFS...
Тогда, имхо, было бы интересно сосредочится не на супербраузере, а о том, чтобы под браузером была спрятана целая инфраструктура по портированию на сторону клиента части функциональности Web-приложения. А именно -- web-браузер, сервер приложений, база данных, средства развертывания, логирования, администрирования и пр. И чтобы это было все унифицированно (чтобы каждое приложение не тащило за собой собственную копию всего этого хозяйства).
Если Коттке и ты, Зверек, правы и подобные приложения действительно имеют хорошие перспективы, то тот, кто выпустит подобный браузер-web-сервер-сервер-приложений действительно начнет доминировать в этом секторе, как Windows на десктопах.
Только если оглянуться на техническую сторону: можно ли создать унифицированную платформу (тот самый супербраузер) при условии, что сейчас есть масса технологий для создания Web-приложений (старые добрые CGI на C/C++ и Perl, Java с со всеми своими наваротами (JSP, JavaServerFaces,Apache наработки), ASP, PHP, Puby on Rails)?
E>>Имхо, сложность создания приложения, которое может работать как на стороне Google/Yahoo/Apple, так и локально на стороне клиента, ну оОочень велика. На стороне контент-провайдера может быть использован специализированный сервер приложений, заточенный под конкретную задачу. Может быть использована специализированная же БД для поддержки фантастически большого объема данных. ЗХ>[...]
ЗХ>Тут со всем практически согласен. Единственное — я имел в виду не совсем stand-alone приложение, а смарт-клиента (как Янус для RSDNa). Перспективы сегодня у таки программ — весьма.
А вот мне интересно насколько общая кодовая база у Януса и у кода самого сайта? Если даже 50% кода обоих приложений различаются, то затраты на выпуск софта в server-side-only и client-side версиях для многих контор могут оказаться слишком большими. А это, имхо, может привести к тому, что выпуском таких приложений будут заниматься только монстры (тот же Yahoo, Google, Apple, Microsoft, AOL).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Тогда, имхо, было бы интересно сосредочится не на супербраузере, а о том, чтобы под браузером была спрятана целая инфраструктура по портированию на сторону клиента части функциональности Web-приложения. А именно -- web-браузер, сервер приложений, база данных, средства развертывания, логирования, администрирования и пр. И чтобы это было все унифицированно (чтобы каждое приложение не тащило за собой собственную копию всего этого хозяйства).
E>Если Коттке и ты, Зверек, правы и подобные приложения действительно имеют хорошие перспективы, то тот, кто выпустит подобный браузер-web-сервер-сервер-приложений действительно начнет доминировать в этом секторе, как Windows на десктопах.
Дисклямер: когда я говорю "супер-браузер", я имею в виду не качество. Супер-браузер — это просто "нечто большее чем браузер", следующая ступень развития этого типа софта. По большому счету, мой вопрос про поиски Шастя с этим классом программ станет ненужным — веб-приложения будут иметь настолько же богатый интерфейс, как обычные, при гибкости и взаимоинтеграции, характерной для веба.
И главная "фенечка" здесь — что браузер не один (соответственно, и никакого доминирования браузера на рынке). Скажем, типичный представитель web2.0 — gmail, одинаково успешно работает в IE, Опере, Файрфоксе, Сафари, ... под Виндой, Линухом, Маком, ... .
Именно поэтому Коттке говорит о закате операционных систем — если вся роль операционной системы сведется к одному "супер-браузеру", рынок изменится довольно сильно.
E>>У Web-приложений есть очень серьезное преимущество по сравнению с desktop-приложениями: кода приложения нет у клиента. Это позволяет контент-провайдеру обновлять свое ПО без необходимости обновления чего-либо у клиента.
ЗХ>ВО!!! А вот тут спасибо — об этом я как-то не сильно задумывался. Вопросы это, конечно, при необходимости, решаемые, но таки весьма проблемные.
Если взять Мозиллу с ее XUL'ом, то 5-40 килобайтов обновлений скачать — это раз плюнуть. Тем более, что broadband нонче — это уже реальность...
Здравствуйте, Mamut, Вы писали:
M>Если взять Мозиллу с ее XUL'ом, то 5-40 килобайтов обновлений скачать — это раз плюнуть. Тем более, что broadband нонче — это уже реальность...
Сижу сейчас на GPRS. Мало того, что 33'600, так еще и 1 мег трафика стоит 1 бакс. Господа, не делайте сайты так, будто у всех халявный гигабитный доступ к инету.
Чушь. Может, конечно, я еще мало выкурил, но имхо автор вообще слабо себе представляет тему.
Каким это интересно образом он собрался обеспечивать независимость приложений от OS? Или он всеръез думает, что можно реализовать весь спектр рич клиентов на джаваскрипте, который будет исполняться браузером? Бред. Опять же значение встроенного в систему веб сервера существенно преувеличена. По хорошему, веб сервер — это крайне тупое приложение, которое всего лишь умеет что-то связное отплевывать в восьмидесятый порт по протоколу HTTP. Для того, чтобы создать веб приложение, нужен какой-то бэкенд код. И совершенно непонятно, почему локальное приложение, ставящее между собой и пользователем браузер с сервером, будет иметь хоть какую-то ценность по сравнению с приложением, работающим напрямую.
В общем, либо мой английский плох, либо коттке пребывает в заблуждении относительно устройства реальных приложений.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
<...> S>В общем, либо мой английский плох, либо коттке пребывает в заблуждении относительно устройства реальных приложений.
Очень вероятно, что Коттке действительно не представляет себе устройства реальных приложений. Но, если посмотреть на высказанные им сумбурные идеи с точки зрения пользователя, то тогда некий смысл появляется. Вот, например, у RSDN есть Web-интерфейс. В котором кроме форумов есть еще масса интересной информации. Так же есть отдельное автономное приложение Janus, которое как бы похоже на RSDN web-интерфейс, но предоставляет только часть информации. И я, как пользователь, должен установить у себя Janus и научится им пользоваться (здесь я утрирую, конечно, но для более сложных случаев это будет актуально), если мне хочется работать с RSDN в offline. При этом Janus предоставляет только часть функциональности rsdn.ru (например, нет оглавления номеров RSDN Mag, нет статей, описаний книг и пр.), хотя и дает мне то, чего нет на rsdn.ru (отметки ответов лично мне, к примеру).
А теперь представим, что получила распространение какая-то технология, которая сделала возможным загрузить с rsdn.ru что-то, после чего я могу через один и тот же web-интерфейс работать с RSDN как в online, так и в offline. И для меня, как для пользователя нет никакого дела, что где-то работает именно web-приложение с rsdn.ru, а где-то -- локально загруженный ко мне код.
Понятно, что с технической точки зрения это все выглядит слишком утопично. Но и AJAX еще лет 10 назад представлялся бы фантастикой. А когда потребность в чем-то a-la AJAX стала критической этот самый AJAX и появился. Если потребность в полу-web/полу-локальных приложениях достигнет критического уровня, то что-то обязательно появится.
Имхо, одним из технических вопросов являтся язык, на котором подобные приложения должны разрабатываться. Но ведь уже сейчас есть большое количество действительно платформенно-независымых языков -- Java, Perl, Python, Ruby, и, усилиями DotGNU и Mono, таковым становится C#. Эти языки вполне можно применять как для создания server-side части, так и для client-side. Поэтому, в крайнем случае, при загрузке к себе web-приложения, клиент может просто получить его в исходных кодах. И, если на его машине установлен соответствующий интрерпритатор/виртуальная машина, запустить приложение. А ведь платформа .Net может сделать еще больше -- она предоставляет скомпилировать в свой байт-код приложения на разных языках (хотя и в Java такое возможно, но Java не стандартизирована). Т.е., можно грузить .Net-овский байт-код, а не исходники.
Естественно, остается еще масса других технических и политических вопросов. Но, имхо, все они будут более-менее разрешены, если будет доказана востребованность подобных комбинированных приложений.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Зверёк Харьковский, Вы писали: E>>У Web-приложений есть очень серьезное преимущество по сравнению с desktop-приложениями: кода приложения нет у клиента. Это позволяет контент-провайдеру обновлять свое ПО без необходимости обновления чего-либо у клиента.
ЗХ>ВО!!! А вот тут спасибо — об этом я как-то не сильно задумывался. Вопросы это, конечно, при необходимости, решаемые, но таки весьма проблемные.
Да ну брось, проблемные. Только что вот порешали у себя...
Дано: сервер приложений с SOAP доступом и клиент на tcl/tk
Клиент собирается откыить очередную форму (код в отдельном файле),
сперва запрашивает у сервера дату северной версии этого файла, если она совпадает с ранее выкачанной —
запускает локалную из кешевого каталога, не совспадает — перекачивает и потом запускает.
И все. Кода, чуть-чуть...
И да, как в веб реализации прикладной код на клиенте отутсвует, только стандартный (и неизменный!)
дистрибут tcl (считай, тот же браузер).
Здравствуйте, eao197, Вы писали:
E>А теперь представим, что получила распространение какая-то технология, которая сделала возможным загрузить с rsdn.ru что-то, после чего я могу через один и тот же web-интерфейс работать с RSDN как в online, так и в offline. И для меня, как для пользователя нет никакого дела, что где-то работает именно web-приложение с rsdn.ru, а где-то -- локально загруженный ко мне код.
Не получится. Различия между янусом и веб-интерфейсом куда глубже, нежели место исполнения кода. Янус и веб интерфейс обладают различной идеологией, поэтому ряд вещей возможен/невозможен там и там по принципиальным моментам, которые никакая технология обойти не поможет.
А задачи прозрачного переноса кода с сервера на клиента вполне решаемы (например в той же 1С 8.0 они решены), только вот практической пользы от этого немного.
Что же касается AJAX то это заплатка. Мне куда больше импонирует XAML.
Здравствуйте, AndrewVK, Вы писали:
E>>А теперь представим, что получила распространение какая-то технология, которая сделала возможным загрузить с rsdn.ru что-то, после чего я могу через один и тот же web-интерфейс работать с RSDN как в online, так и в offline. И для меня, как для пользователя нет никакого дела, что где-то работает именно web-приложение с rsdn.ru, а где-то -- локально загруженный ко мне код.
AVK>Не получится. Различия между янусом и веб-интерфейсом куда глубже, нежели место исполнения кода. Янус и веб интерфейс обладают различной идеологией, поэтому ряд вещей возможен/невозможен там и там по принципиальным моментам, которые никакая технология обойти не поможет.
Вполне возможно, что это из-за того, что такой задачи не стоит. А вот если Google очень сильно захочет сделать возможным локальную offline-работу с GMail, то какую-нибудь технологию для этого они придумают. ИМХО.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вполне возможно, что это из-за того, что такой задачи не стоит. А вот если Google очень сильно захочет сделать возможным локальную offline-работу с GMail, то какую-нибудь технологию для этого они придумают. ИМХО.
Здравствуйте, AndrewVK, Вы писали:
E>>Вполне возможно, что это из-за того, что такой задачи не стоит. А вот если Google очень сильно захочет сделать возможным локальную offline-работу с GMail, то какую-нибудь технологию для этого они придумают. ИМХО.
AVK>Еще раз повторю — дело не в технологии.
Точно так же и я повторю -- дело в потребности и желании.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
S>Чушь. Может, конечно, я еще мало выкурил, но имхо автор вообще слабо себе представляет тему. S>Каким это интересно образом он собрался обеспечивать независимость приложений от OS? Или он всеръез думает, что можно реализовать весь спектр рич клиентов на джаваскрипте, который будет исполняться браузером? Бред. Опять же значение встроенного в систему веб сервера существенно преувеличена. По хорошему, веб сервер — это крайне тупое приложение, которое всего лишь умеет что-то связное отплевывать в восьмидесятый порт по протоколу HTTP. Для того, чтобы создать веб приложение, нужен какой-то бэкенд код. И совершенно непонятно, почему локальное приложение, ставящее между собой и пользователем браузер с сервером, будет иметь хоть какую-то ценность по сравнению с приложением, работающим напрямую. S>В общем, либо мой английский плох, либо коттке пребывает в заблуждении относительно устройства реальных приложений.
Ну, давайте-ка я прикинусь адвокатом дьявола (в том смысле, что кто здесь прав я покуда не уверен, но for fun буду защищать Коттку).
Попробуем прикинуть (в нижеследующем тексте под термином "desktop-приложение" имеется в виду самостоятельная программа; "web-приложение" — HTML+JavaScript, работающее в любом современном браузере).
Преимущества desktop-приложений
1. Существенно более богатые возможности по созданию интерфейса
2. Нет проблем с хранением данных на клиенте
3. (наиболее очевидное) Не нужно постоянное подключение к интернету
Преимущества web-приложений
1. Непривязанность к конкретному компьютеру
2. Легкость совместной работы (к примеру, некое потенциальное webIDE бесшовно и естественно интегрируется с VCS)
3. Полное отсутствие проблемы смены версии (с точки зрения клиента)
Давайте по возможности дополним оба списка (но без фанатизма!) — а потом посмотрим, что у нас получилось. Есть мнение, что придется переосмыслять привычные понятия о возможностях web/desktop.
Здравствуйте, eao197, Вы писали:
E>Вполне возможно, что это из-за того, что такой задачи не стоит. А вот если Google очень сильно захочет сделать возможным локальную offline-работу с GMail, то какую-нибудь технологию для этого они придумают. ИМХО.
Такая технология существует уже десять лет. Я намекну: ты давно в последний раз видел жабный апплет? А ее ведь специально проектировали с расчетом на то, что код будет загружаться по требованию.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Не понятно, причем здесь OS? OS (операционная система) -- это прослойка между железом и прикладными программами. Здесь же речь идет о новых принципах создания приложений. Но эти принципы, имхо, совершенно никак не повлияют на роль и значимость именно операционных систем (Windows, MacOS, Linux, *BSD, ...). Так что один из возможных заголовков: "Finally, the end of Microsoft's operating system dominance" вообще к содержанию статьи, имхо, не имеет никакого отношения.
Очень даже имеет. Как говорится, "слово утратило былое звучание" (или как там, у Эдгара По?). Сейчас OS — это не просто прослойка — это целая религия! Но люди не хотят гегемонизма. Точнее сказать, некоторое время вроде бы и хотят, но потом задают резонный вопрос — "а где же нас кидают?" — и ведь кидают же! Так устроен этот мир, и поэтому не видать гегемонизма ни Микрософту, ни Линуксу, ни кому бы то ни было еще. И это, соратники, наполняет нас невыразимым блаженством. Аминь.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Попробуем прикинуть (в нижеследующем тексте под термином "desktop-приложение" имеется в виду самостоятельная программа; "web-приложение" — HTML+JavaScript, работающее в любом современном браузере).
ЗХ>Преимущества desktop-приложений ЗХ>1. Существенно более богатые возможности по созданию интерфейса ЗХ>2. Нет проблем с хранением данных на клиенте ЗХ>3. (наиболее очевидное) Не нужно постоянное подключение к интернету
4. Экономия трафика за счет того, что можно значительно гибче кешировать оформление (именно оно отнимает львиную долю трафика в веб-приложениях) и передавать практически голые данные. А так же за счет того, что можно локально хранить большие объемы данных.
5. Более полный доступ к локальным устройствам — устройствам вывода на твердую копию, постоянным и съемным носителям, устройствам ручного ввода, 3D-акселераторам и т.п. Доступ ко внутренним сетевым ресурсам.
6. Более глубокие возможности по адаптации к различным клиентским устройствам — планшетам, КПК, мобильникам и т.д.
ЗХ>Преимущества web-приложений ЗХ>1. Непривязанность к конкретному компьютеру ЗХ>2. Легкость совместной работы (к примеру, некое потенциальное webIDE бесшовно и естественно интегрируется с VCS)
Это вряд ли. Проблемы параллельного доступа к единым ресурсам нужно решать что для веб-приложений, что для смарт-клиентов. Разницы между ними в этом плане никакой.
ЗХ>3. Полное отсутствие проблемы смены версии (с точки зрения клиента)
Для смарт клиентов эта проблема решается сравнительно небольшой кровью.
4. Простота старта. Ничего копировать и устанавливать не надо. Правда есть Java WebStart и MS ClickOnce
