Будущее уже сейчас

Всем уже более-менее понятно, в каком направлении развиваются технологии. Подход к данным становится настолько унифицирован, что их почти всегда стало возможным рассматривать как отдельную сущность, безотносительно к проги, которой они созданы. И чем дальше данные отходят от своего софта — тем четче становится понятное: данные всегда должны быть доступны.

Но и проги всегда должны быть доступны ТОЖЕ!

Ясно, куда я веду? схема проста: данные должны быть где-то на вебе, клиент (что с ними работает) — тоже на вебе (это не обязательно, но почему нет, если такая возможность существует?). И это не просто потому, что веб отовсюду доступен, а вы хотите, чтобы ваши данные и клиенты, которые с ними работают, были отовсюду доступны; нет, просто потому, что веб надежнее. Винты на гугл-плекс надежнее, чем ваш винт (чем мой точно, он у меня как раз недавно сгорел 🙁 (пропало все, кроме того, что было на вебе …)). А я занимался темой: проектирование систем кондиционирования. Пришлось заново доделывать некоторые моменты.

Данные всегда были врозь — в виде файлов они хранились у вас на винте; что мешает им сохраняться в виде баз данных на винте у гугла (например)? если их винты надежнее, а базы данных – имеют более унифицированный подход? С приложениями все не так очевидно (обычно вы работаете с локальными клиентами, которые установлены на вашем компьютере), но работая в Интернете, вы постоянно сталкиваетесь с приложениями, которые выполняются на серверах (например страницы этого блога динамично генерируются из php-кода, выполненного на серваке), а если вы пользуетесь веб-приложениями типа google docs, то вообще понимаете, о чем я. Но есть еще более радикальный тип «интернет-приложений»: т.н.  rich internet applications. Они делают шаг за пределы браузера и представляют собой обычные приложения, выполняемые в своем окне, могут работать с обычными локальными данными и т.д. (Представьте себе writely (google docs), который выполняется не в браузере, а в своем окне, как ворд, например). В отличие от веб-приложений они выполняют «серверную часть» процедур на клиентском компе. Основные преимущества таких программ — отовсюду-доступность, кроссплатформенность, маленький размер, быстрая инсталляция и обновление (недостатки: интерпретация (скорость) + см. Ниже).

Вообще «против» веб-подхода существует несколько моментов. Основные:

  1. скорость — интернет просто еще не настолько быстр, как винт; но для многих задач и объемов (документы, фотки …) его скорость уже приемлема;
  2. приватность — не все согласятся хранить свои документы например на writely, потому что в них может содержаться «чувствительная» информация, доступ к которой желательно чтобы был единоличный. Но я не рассматриваю пока этот аргумент.
  3. Главное же, что отличает работу с данными в Интернете от работы с данными на винте, — это страшный ОФЛАЙН.

По любым причинам внезапно вы можете оказаться офлайн — и все! ваши данные недоступны! вы не можете с ними работать! ЭТО главная неприятность веб-данных. Если преодолеть ее — можно считать, что  будет преодолена, что называется избыточная «централизация» веба, сверхзависимость от «онлайна».

И уже сейчас существуют два основных решения проблемы (пока бета): AIR (Adobe Integrated Runtime) и Google Gears.

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

Так в чем прикол AIR и Google Gears? — Они предлагают готовое кроссплатформенное API для этого: а) в случае AIR это создание полноценных интернет-приложений, б) в случае Google Gears это «масштабирование» вашего готового ajax-кода для работы режиме.

Если в двух словах:

AIR — рантайм, интерпретатор (типа. Нет, объявления), который раз устанавливается на клиентский компьютер и «исполняет» AIR-приложения. Разрабатывать проги (и масштабировать существующие) можно на основе Flex-Flash или HTML-яваскрипта. (Кстати, AIR — это бета-версия того, что еще совсем недавно в альфа-варианте назывался Apollo ;-)). Можно скачать кучу примеров, посмотреть-потыкать…  Из уже работающих решений: pownce  вы будете смеяться, но это — инстант-мессенджер, но полностью реализован как интернет-приложение, со всеми преимуществами такого решения (в частности: вы можете пользоваться им в браузере, а можете — в клиенте; сервис один, код работает один, разные только интерфейсы …)

Google Gears — екстеншн под IE и файерфокс (поддержка оперы ожидается …) качается, устанавливается, работает. Как пример, можно посмотреть на Google Reader — после установки gears в файерфоксе там появится такая стрелка «офлайн», когда кликает ее — на ваш комп скачивается база последних постов (пока без картинок), в дальнейшем вы можете «ходить» по ним, читать, отмечать прочитанные вообще пользоваться всей обычной функциональностью google reader, и все это оффлайн! как только вы кликните «онлайн» — все данные синхронизируются с вашим аккаунтом ридера! <- Вот где вся нехитрая фантастика ситуации …

Bottom-line: на одном форуме встречал я человека, который имел желание написать прогу, которая вела бы список аниме. Это просто совершенно классический пример для применения интернет-приложений. Все мы знаем, как это должно быть примерно: MyAnimeList.net. Но правильное решение для такой проги — то же, но как сервис:

  1. возможность не просто работать со своими данными онлайн (как сейчас) — но и ВНЕ (типа Google Gears) (я должен иметь возможность обновлять базу аниме, даже находясь оффлайн, и когда я выхожу онлайн — база должна синхронизироваться!)
  2. плюс к этому возможность работать вне браузера, в отдельном окне (вариант типа AIR)

Зачем мне знать вообще — онлайн я или офлайн? Это должна знать прога (или браузер, в котором я в данный момент работаю) — и она автоматически должна синхронизировать меня с моими данными в интернете! Разница между интернетом и вашим винт — чисто техническая, формальная; по сути ее не существует, и постепенно она сотрется. <- Это будущее; или реализовывать это посредством AIR? или объявления? или более низкоуровнево? — Это ваш выбор; главное результат: прога должна работать с данными прозрачно, независимо от того, онлайн они или оффлайн, данные должны быть и здесь, и там, и локально, и на вебе — прога, кроме всего прочего, должна поддерживать их в синхронизированном состоянии. (Кстати, локальная база данных как в AIR, так и в Google Gears реализована на основе sqlite ;-)).

И рассматривать такой подход к решению проблемы аниме-списков, например, как в виде локальной проги, работающий с локальными данными — это даже неуместно … Это просто не время.