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
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Попробуем прикинуть (в нижеследующем тексте под термином "desktop-приложение" имеется в виду самостоятельная программа; "web-приложение" — HTML+JavaScript, работающее в любом современном браузере).
ЗХ>>Преимущества desktop-приложений ЗХ>>1. Существенно более богатые возможности по созданию интерфейса ЗХ>>2. Нет проблем с хранением данных на клиенте ЗХ>>3. (наиболее очевидное) Не нужно постоянное подключение к интернету AVK>4. Экономия трафика за счет того, что можно значительно гибче кешировать оформление (именно оно отнимает львиную долю трафика в веб-приложениях) и передавать практически голые данные. А так же за счет того, что можно локально хранить большие объемы данных.
Ну, во-первых, кеширование еще никто не отменял (картинок, стилей и прочего).
Во-вторых, как там Влад говорит? "Память сегодня не ресурс"? Ну и трафик потихоньку перестает быть.
AVK>5. Более полный доступ к локальным устройствам — устройствам вывода на твердую копию, постоянным и съемным носителям, устройствам ручного ввода, 3D-акселераторам и т.п. Доступ ко внутренним сетевым ресурсам.
Факт.
AVK>6. Более глубокие возможности по адаптации к различным клиентским устройствам — планшетам, КПК, мобильникам и т.д.
Хмы... Эттто еще вопрос, что проще подогнать под КПК-шку
Давеча в КТ писали — Опера сделала браузер для мобил, в котором можно смотреть обычные сайты (она их переформатирует). Вплот до беспроблемного использования GMail.
ЗХ>>Преимущества web-приложений ЗХ>>1. Непривязанность к конкретному компьютеру ЗХ>>2. Легкость совместной работы (к примеру, некое потенциальное webIDE бесшовно и естественно интегрируется с VCS)
AVK>Это вряд ли. Проблемы параллельного доступа к единым ресурсам нужно решать что для веб-приложений, что для смарт-клиентов. Разницы между ними в этом плане никакой.
Ну, некоторая разница все же есть. Когда ресурсы заведомо хранятся централизовано (на сервере), то кой-чаго становится проще (по крайней мере, с т.з. клиента).
ЗХ>>3. Полное отсутствие проблемы смены версии (с точки зрения клиента)
AVK>Для смарт клиентов эта проблема решается сравнительно небольшой кровью.
Угу, скачиваешь новую версию Януса, реструктурируешь БД... Делов-то.
За что я люблю MSN Messenger — раз в месяц он сообщает "этот вэрсия болше не работает,да?" — и качает новую самостоятельно Мегабайта 3-4. По дайлапу...
AVK>4. Простота старта. Ничего копировать и устанавливать не надо. Правда есть Java WebStart и MS ClickOnce
Здравствуйте, Sinclair, Вы писали:
E>>Вполне возможно, что это из-за того, что такой задачи не стоит. А вот если Google очень сильно захочет сделать возможным локальную offline-работу с GMail, то какую-нибудь технологию для этого они придумают. ИМХО. S>Такая технология существует уже десять лет. Я намекну: ты давно в последний раз видел жабный апплет? А ее ведь специально проектировали с расчетом на то, что код будет загружаться по требованию.
Нет, как раз недавно видел. LiveTiming на сайте Formula-1 как раз в виде апплета сделан. Очень интересно, если нет возможности этап по TV посмотреть.
Но, имхо, это опять не то. Очевидно, что код web-приложения GMail и код Java-апплета для offline-клиента для GMail очевидно будут слишком разными и не будут иметь общей кодовой базы. А представь себе, что с помощью какой-то прослойки появляется возможность взять серверный код GMail и заставить его работать у клиента в offline! С локальным частичным snapshot-ом почтовой базы клиента. Вроде того, что когда нет связи с сервером GMail-клиент работает только с тем, что оказалось на машине клиента. Когда связь появляется сама прослойка берет на себя задачу синхронизации локальной и серверной БД. И прозрачно перенаправляет запросы с локальной БД на серверную при необходимости. А так же кэширует части серверной БД на клиенте.
В браузерах ведь что-то подобное уже есть. Они же кэшируют у себя часть котента чтобы не качать повторно то, что не изменилось на сервере.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Ну, во-первых, кеширование еще никто не отменял (картинок, стилей и прочего).
Значительно менее гибко.
ЗХ>Во-вторых, как там Влад говорит? "Память сегодня не ресурс"? Ну и трафик потихоньку перестает быть.
Это вряд ли. Коммуникационным каналам еще очень далеко до насыщения потребностей, в отличие от памяти. А есть еще повышение нагрузки не сервера, у которых тоже масштабируемость не бесконечна.
AVK>>6. Более глубокие возможности по адаптации к различным клиентским устройствам — планшетам, КПК, мобильникам и т.д. ЗХ>Хмы... Эттто еще вопрос, что проще подогнать под КПК-шку
Главное не что проще, а чей результат будет качественней.
ЗХ>Давеча в КТ писали — Опера сделала браузер для мобил, в котором можно смотреть обычные сайты (она их переформатирует). Вплот до беспроблемного использования GMail.
Как будто он первый. Только вот удобство такого решения хромает.
AVK>>Это вряд ли. Проблемы параллельного доступа к единым ресурсам нужно решать что для веб-приложений, что для смарт-клиентов. Разницы между ними в этом плане никакой.
ЗХ>Ну, некоторая разница все же есть.
Ну, судя по моему опыту, все таки нет. Хотя, конечно, это отчасти субъективно.
AVK>>Для смарт клиентов эта проблема решается сравнительно небольшой кровью.
ЗХ>Угу, скачиваешь новую версию Януса, реструктурируешь БД... Делов-то.
В янусе эту проблему не решали из-за не очень большой актуальности (и сложности регулярного выпуска стабильных версий). Поэтому, кстати, формально смарт-клиентом с точки зрения МС янус не является.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Для смарт клиентов эта проблема решается сравнительно небольшой кровью.
ЗХ>>Угу, скачиваешь новую версию Януса, реструктурируешь БД... Делов-то.
AVK>В янусе эту проблему не решали из-за не очень большой актуальности (и сложности регулярного выпуска стабильных версий). Поэтому, кстати, формально смарт-клиентом с точки зрения МС янус не является.
Во, это интересно. Можешь вкратце сказать (или ткнуть меня носом в линк, я не обижусь), каковы формальные требования к "смарт-клиенту"?
Здравствуйте, Зверёк Харьковский, Вы писали:
AVK>>В янусе эту проблему не решали из-за не очень большой актуальности (и сложности регулярного выпуска стабильных версий). Поэтому, кстати, формально смарт-клиентом с точки зрения МС янус не является.
ЗХ>Во, это интересно. Можешь вкратце сказать (или ткнуть меня носом в линк, я не обижусь), каковы формальные требования к "смарт-клиенту"?
Здравствуйте, eao197, Вы писали: E>Но, имхо, это опять не то. Очевидно, что код web-приложения GMail и код Java-апплета для offline-клиента для GMail очевидно будут слишком разными и не будут иметь общей кодовой базы.
Почему это? E>А представь себе, что с помощью какой-то прослойки появляется возможность взять серверный код GMail и заставить его работать у клиента в offline! Существующий код GMail, очевидно, не станет так работать. Просто потому, что он не портабелен. Был бы написан на джаве — работал бы на клиентской машине, и в том числе оффлайн. E>С локальным частичным snapshot-ом почтовой базы клиента.
С этим пока хуже, по соображениям секурности. E>Вроде того, что когда нет связи с сервером GMail-клиент работает только с тем, что оказалось на машине клиента. Когда связь появляется сама прослойка берет на себя задачу синхронизации локальной и серверной БД. И прозрачно перенаправляет запросы с локальной БД на серверную при необходимости. А так же кэширует части серверной БД на клиенте.
Это все понятно. Непонятно, как это будет работать. Потому что логика и структура клиентского приложения радикальнейшим образом отличается от того, что делается на сервере.
Почему? Потому, что сервер работает в совершенно другом окружении. Поднять полную копию environment сервера на клиенте — пока что анриал. До тех пор, пока OS не начнет предоставлять огромное количество сервисов. Для начала: в чем ты собрался хранить данные? В реляционной базе? Угу, покажи мне СУБД, которая масштабируется от однопользовательской клиентской версии до full-scale сервера на стороне GMail. Чтобы можно было использовать для работы с ней один и тот же код.
При этом, конечно же, эта СУБД должна либо быть на всех платформах, как джава-машина, либо быть платформеннонезависимой и скачиваться on demand. Иначе мы потеряем главный плюс веб-приложений. А для работы GMail нужна далеко не только СУБД. Еще очень много сервисов должны быть доступны локально — иначе мы получаем все того же тонкого клиента, который сейчас живет в рамках браузера. E>В браузерах ведь что-то подобное уже есть. Они же кэшируют у себя часть котента чтобы не качать повторно то, что не изменилось на сервере.
Во-первых, они кэшируют только "вниз". Никакой возможности синхронизоваться "вверх" на основе браузерного кэша нету. И там вообще другая идеология: браузер кэширует не данные, а результаты запросов. Они устроены совершенно по-другому, чем данные на сервере. Поэтому все это вообще работает.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Попробуем прикинуть (в нижеследующем тексте под термином "desktop-приложение" имеется в виду самостоятельная программа; "web-приложение" — HTML+JavaScript, работающее в любом современном браузере).
ЗХ>>Преимущества desktop-приложений ЗХ>>1. Существенно более богатые возможности по созданию интерфейса ЗХ>>2. Нет проблем с хранением данных на клиенте ЗХ>>3. (наиболее очевидное) Не нужно постоянное подключение к интернету AVK>4. Экономия трафика за счет того, что можно значительно гибче кешировать оформление (именно оно отнимает львиную долю трафика в веб-приложениях) и передавать практически голые данные. А так же за счет того, что можно локально хранить большие объемы данных.
Используйте Java WebStart. AVK>5. Более полный доступ к локальным устройствам — (a) устройствам вывода на твердую копию, (b) постоянным и съемным носителям, (c) устройствам ручного ввода, (d) 3D-акселераторам и т.п. (e) Доступ ко внутренним сетевым ресурсам.
5.a. Java Printing API
5.b. Java IO API
5.c. Java Look'and'Feel
5.d. Java3D независима от платформы.
5.e. ??? Java Network API AVK>6. Более глубокие возможности по адаптации к различным клиентским устройствам — планшетам, КПК, мобильникам и т.д.
Используйте Java Accessibility API.
<...> ЗХ>>3. Полное отсутствие проблемы смены версии (с точки зрения клиента) AVK>Для смарт клиентов эта проблема решается сравнительно небольшой кровью.
Используйте Java WebStart для рич-клиентов. AVK>4. Простота старта. Ничего копировать и устанавливать не надо. Правда есть Java WebStart и MS ClickOnce
Вот именно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Но, имхо, это опять не то. Очевидно, что код web-приложения GMail и код Java-апплета для offline-клиента для GMail очевидно будут слишком разными и не будут иметь общей кодовой базы. S>Почему это?
Ну хотя бы потому, что web-приложение формирует свой GUI на основе HTML и JavaScript. А Java-апплет на основе GUI-widget-ов. Web-приложение имеет возможность обращатся на прямую к БД, а вот Java-апплету придется как-то у сервера данные запрашивать.
E>>Вроде того, что когда нет связи с сервером GMail-клиент работает только с тем, что оказалось на машине клиента. Когда связь появляется сама прослойка берет на себя задачу синхронизации локальной и серверной БД. И прозрачно перенаправляет запросы с локальной БД на серверную при необходимости. А так же кэширует части серверной БД на клиенте. S>Это все понятно. Непонятно, как это будет работать. Потому что логика и структура клиентского приложения радикальнейшим образом отличается от того, что делается на сервере.
<...следующие два абзаца поскипаны...>
Но тем не менее... Скажем, ты просишь меня показать СУБД, которая маштабируется. А вот мне кажется, что если приложение использует стандартный, не привязанный к конкретной СУБД, SQL то совсем не обязательно, имхо, чтобы у клиента на машине была таже СУБД, что и на сервере.
Ну и кроме того, если уж фантазировать, то можно провести аналогию. Сейчас, чтобы пользоваться Web-ом, нужно иметь браузер. И практически на всех десктопах браузеры есть. Причем все они настолько близки по функциональности, что по большому счету без разницы, пользуемся ли мы Оперой, Эксплорером, Мозилой, Сафари, Канкуером или еще чем-то. Как раз это и делает web-приложения платформенно-независимыми с точки зрения конечного пользователя -- ведь я вижу тоже самое на rsdn.ru и когда захожу в него Оперой из Windows, и когда Канкуером из Linux-а.
Теперь представим, что появляется какой-то набор инструментов, который позволяет создать на машине пользователя какое-то подобие server-side окружения. Ведь выпускает Sun спецификации вроде EJB, JDBC, JDO, JMS... Ну появится еще несколько спецификаций для web-приложений. Таких, что написанное в их соотвествии web-приложение сможет работать и на клиенте. Причем на сервере могут быть установлены мощные, дорогие системы, реализующие данные спецификации. А на клиенте более простые, менее требовательные. Но все равно они будут предоставлять приложению привычное окружение.
С точки зрения наших сегодняшних знаний все это выглядит утопичным. Но ведь до появления реляционных СУБД как-то работали люди на иерархических и сетевых СУБД. Потом появились РСУБД и это стало прорывом. С web-мо, имхо, тоже самое -- статический контент, CGI, web-приложения, ... Что-то же все равно будет дальше. И когда это что-то появится мы будем думать, да все элементарно -- берем такую то технологию, устанавливаем такой-то софт и понеслось. До следующей не разрешимой задачи. Потом опять -- технология, инструмент, новая задача. И т.д.
В конце-концов, мы ведь в "Философии программирования". Почему бы и не пофилософствовать
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, iZEN, Вы писали:
AVK>>4. Экономия трафика за счет того, что можно значительно гибче кешировать оформление (именно оно отнимает львиную долю трафика в веб-приложениях) и передавать практически голые данные. А так же за счет того, что можно локально хранить большие объемы данных. ZEN>Используйте Java WebStart.
Это из другой оперы.
AVK>>5. Более полный доступ к локальным устройствам — (a) устройствам вывода на твердую копию, (b) постоянным и съемным носителям, (c) устройствам ручного ввода, (d) 3D-акселераторам и т.п. (e) Доступ ко внутренним сетевым ресурсам. ZEN>5.a. Java Printing API ZEN>5.b. Java IO API ZEN>5.c. Java Look'and'Feel ZEN>5.d. Java3D независима от платформы. ZEN>5.e. ??? Java Network API AVK>>6. Более глубокие возможности по адаптации к различным клиентским устройствам — планшетам, КПК, мобильникам и т.д. ZEN>Используйте Java Accessibility API. ZEN><...>
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, eao197, Вы писали: E>>>Но, имхо, это опять не то. Очевидно, что код web-приложения GMail и код Java-апплета для offline-клиента для GMail очевидно будут слишком разными и не будут иметь общей кодовой базы. S>>Почему это? E>Ну хотя бы потому, что web-приложение формирует свой GUI на основе HTML и JavaScript. А Java-апплет на основе GUI-widget-ов. Web-приложение имеет возможность обращатся на прямую к БД, а вот Java-апплету придется как-то у сервера данные запрашивать.
Интересно, а если прямой JDBC-запрос сделать невозможно по причине отсутствия драйвера 4-го уровня (написан на Java) и/или закрыты все "нестандартные" порты кроме http? Если не через JDBC, то как же?
Всё просто: jdbc-запрос кодируется в http GET/POST-запрос (Request). На сервере, соответственно, происходит раскодирование, выполнение запроса и отправка данных клиенту в соответствующем "конверте", определяемом MIME-типом (Response).
Здравствуйте, iZEN, Вы писали:
E>>>>Но, имхо, это опять не то. Очевидно, что код web-приложения GMail и код Java-апплета для offline-клиента для GMail очевидно будут слишком разными и не будут иметь общей кодовой базы. S>>>Почему это? E>>Ну хотя бы потому, что web-приложение формирует свой GUI на основе HTML и JavaScript. А Java-апплет на основе GUI-widget-ов. Web-приложение имеет возможность обращатся на прямую к БД, а вот Java-апплету придется как-то у сервера данные запрашивать. ZEN>Интересно, а если прямой JDBC-запрос сделать невозможно по причине отсутствия драйвера 4-го уровня (написан на Java) и/или закрыты все "нестандартные" порты кроме http? Если не через JDBC, то как же? ZEN>Всё просто: jdbc-запрос кодируется в http GET/POST-запрос (Request). На сервере, соответственно, происходит раскодирование, выполнение запроса и отправка данных клиенту в соответствующем "конверте", определяемом MIME-типом (Response).
Ну правильно, именно это я и имел в виду. Но вот разве нужно все это web-приложению, которое работает на сервере и имеет возможность непосредственно осуществлять JDBC запросы к БД? Имхо, нет в этом смысла.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Ну хотя бы потому, что web-приложение формирует свой GUI на основе HTML и JavaScript. А Java-апплет на основе GUI-widget-ов. Web-приложение имеет возможность обращатся на прямую к БД, а вот Java-апплету придется как-то у сервера данные запрашивать.
Это понятно. Нет никакой технологии чтобы превратить готовое веб-приложение на хренпоймичем в локальное приложение с использованием той же базы. А вот с нуля написать приложение, которое будет работать как applet и как standalone — можно.
E>Здесь ты, имхо, повторил тоже, что я говорил тут: Re: Показалось достойным внимания
.
Совершенно верно. E>Но тем не менее... Скажем, ты просишь меня показать СУБД, которая маштабируется. А вот мне кажется, что если приложение использует стандартный, не привязанный к конкретной СУБД, SQL то совсем не обязательно, имхо, чтобы у клиента на машине была таже СУБД, что и на сервере.
Здесь ключевое слово — "кажется". Потому что такой вещи, как "стандартный, не привязанный к конкретной СУБД SQL" в природе не существует. Существует бездна диалектов, которые отличаются настолько, что невозможно построить мало-мальски сложное приложение независимым от СУБД образом.
E>Теперь представим, что появляется какой-то набор инструментов, который позволяет создать на машине пользователя какое-то подобие server-side окружения. Ведь выпускает Sun спецификации вроде EJB, JDBC, JDO, JMS... Ну появится еще несколько спецификаций для web-приложений. Таких, что написанное в их соотвествии web-приложение сможет работать и на клиенте. Причем на сервере могут быть установлены мощные, дорогие системы, реализующие данные спецификации. А на клиенте более простые, менее требовательные. Но все равно они будут предоставлять приложению привычное окружение.
Вот это все — тоже утопия. Может, я мало курил, но я не представляю себе такую замечательную спецификацию, которая была бы достаточно lightweight для работы на клиенте, и достаточно fullscale для использования на сервере.
E>С точки зрения наших сегодняшних знаний все это выглядит утопичным. Но ведь до появления реляционных СУБД как-то работали люди на иерархических и сетевых СУБД. Потом появились РСУБД и это стало прорывом. С web-мо, имхо, тоже самое -- статический контент, CGI, web-приложения, ... Что-то же все равно будет дальше. И когда это что-то появится мы будем думать, да все элементарно -- берем такую то технологию, устанавливаем такой-то софт и понеслось. До следующей не разрешимой задачи. Потом опять -- технология, инструмент, новая задача. И т.д.
Ага. Ну то есть предлагается называть вот такой вот Environment собственно WebOS. Я правильно понял полет фантазии?
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
iZEN>>Всё просто: jdbc-запрос кодируется в http GET/POST-запрос (Request). На сервере, соответственно, происходит раскодирование, выполнение запроса и отправка данных клиенту в соответствующем "конверте", определяемом MIME-типом (Response).
E>Ну правильно, именно это я и имел в виду. Но вот разве нужно все это web-приложению, которое работает на сервере и имеет возможность непосредственно осуществлять JDBC запросы к БД? Имхо, нет в этом смысла.
Тогда технология Агентов.
Агент может быть построен/создан на лету в клиентском приложении для выполнения определённых задач от лица пользователя на сервере. Его можно сериализовать (вместе с соответствующими .class-файлом/ами) в бинарный код и отправить в http GET/POST-запросе на сервер, там его уже "ждут", "разворачивают" и запускают с правами соответствующего пользователя. Дальше уже дело техники.
Либо универсальные XML-RPC или SOAP, "работающие" по такому же принципу.
Но для SOAP нужна унифицированная инфраструктура как на клиенте, так и на сервере, что усложняет переносимость (меньше кода — лучше переносимость). XML-RPC в этом плане более легковесен, так как вокруг него не нужно городить огород из фрейморка, соответствующего какой-либо полной спецификации. Задача усложняется тем, "поймут" ли друг друга клиент и сервер, если они сами по себе должны быть независимыми. Что делать серверу, если ему пришлют "какой-то" XML неизвестно от кого: отшить или провести процесс авторизации. "Договориться" с клиентом на каком языке?
Здравствуйте, iZEN, Вы писали:
iZEN>>>Всё просто: jdbc-запрос кодируется в http GET/POST-запрос (Request). На сервере, соответственно, происходит раскодирование, выполнение запроса и отправка данных клиенту в соответствующем "конверте", определяемом MIME-типом (Response).
E>>Ну правильно, именно это я и имел в виду. Но вот разве нужно все это web-приложению, которое работает на сервере и имеет возможность непосредственно осуществлять JDBC запросы к БД? Имхо, нет в этом смысла. ZEN>Тогда технология Агентов. ZEN>Агент может быть построен/создан на лету в клиентском приложении для выполнения определённых задач от лица пользователя на сервере. Его можно сериализовать (вместе с соответствующими .class-файлом/ами) в бинарный код и отправить в http GET/POST-запросе на сервер, там его уже "ждут", "разворачивают" и запускают с правами соответствующего пользователя. Дальше уже дело техники.
<...>
Все это хорошо, но не решает главной проблемы -- заливке web-приложения на сторону клиента и работе его там в offline. Причем практически полноценной работе.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
E>>С точки зрения наших сегодняшних знаний все это выглядит утопичным. Но ведь до появления реляционных СУБД как-то работали люди на иерархических и сетевых СУБД. Потом появились РСУБД и это стало прорывом. С web-мо, имхо, тоже самое -- статический контент, CGI, web-приложения, ... Что-то же все равно будет дальше. И когда это что-то появится мы будем думать, да все элементарно -- берем такую то технологию, устанавливаем такой-то софт и понеслось. До следующей не разрешимой задачи. Потом опять -- технология, инструмент, новая задача. И т.д. S>Ага. Ну то есть предлагается называть вот такой вот Environment собственно WebOS. Я правильно понял полет фантазии?
Ага.
По крайней мере для себя смысл в путанных изъяснениях г.Коттке я нашел именно в этом.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Ну хотя бы потому, что web-приложение формирует свой GUI на основе HTML и JavaScript. А Java-апплет на основе GUI-widget-ов. Web-приложение имеет возможность обращатся на прямую к БД, а вот Java-апплету придется как-то у сервера данные запрашивать. S>Это понятно. Нет никакой технологии чтобы превратить готовое веб-приложение на хренпоймичем в локальное приложение с использованием той же базы. А вот с нуля написать приложение, которое будет работать как applet и как standalone — можно.
E>>Здесь ты, имхо, повторил тоже, что я говорил тут: Re: Показалось достойным внимания
. S>Совершенно верно. E>>Но тем не менее... Скажем, ты просишь меня показать СУБД, которая маштабируется. А вот мне кажется, что если приложение использует стандартный, не привязанный к конкретной СУБД, SQL то совсем не обязательно, имхо, чтобы у клиента на машине была таже СУБД, что и на сервере. S>Здесь ключевое слово — "кажется". Потому что такой вещи, как "стандартный, не привязанный к конкретной СУБД SQL" в природе не существует. Существует бездна диалектов, которые отличаются настолько, что невозможно построить мало-мальски сложное приложение независимым от СУБД образом.
E>>Теперь представим, что появляется какой-то набор инструментов, который позволяет создать на машине пользователя какое-то подобие server-side окружения. Ведь выпускает Sun спецификации вроде EJB, JDBC, JDO, JMS... Ну появится еще несколько спецификаций для web-приложений. Таких, что написанное в их соотвествии web-приложение сможет работать и на клиенте. Причем на сервере могут быть установлены мощные, дорогие системы, реализующие данные спецификации. А на клиенте более простые, менее требовательные. Но все равно они будут предоставлять приложению привычное окружение. S>Вот это все — тоже утопия. Может, я мало курил, но я не представляю себе такую замечательную спецификацию, которая была бы достаточно lightweight для работы на клиенте, и достаточно fullscale для использования на сервере.
Borland JDataStore — пример переносимой СУБД-SQL на Java для embedded-систем. Кстати, BES в ней хранит записи о транзакциях — вроде не падает и не жалуется на "немасштабируемость".
Для клиентского приложения достаточно ядра (один файлик .jar) этой СУБД для полного переноса её функционала на сторону клиента. Поддерживаются как прямое обращение клиента к JDataStore (на этапе написания кода: import <jds package>), так и в рантайме по JDBC-протоколу (драйвер 4-типа).
извиняюсь, что подымаю тему (ищю кое-какую информацию)...
E>>А представь себе, что с помощью какой-то прослойки появляется возможность взять серверный код GMail и заставить его работать у клиента в offline!
прошло всего два года... а уже реальность наступила — Google Gear, XULrunner, Mozilla Prizm
S>Существующий код GMail, очевидно, не станет так работать. Просто потому, что он не портабелен. Был бы написан на джаве — работал бы на клиентской машине, и в том числе оффлайн. E>>С локальным частичным snapshot-ом почтовой базы клиента. S>С этим пока хуже, по соображениям секурности.
...
Мегабайта 3-4. По дайлапу...
