Здравствуйте, 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. По дайлапу...
