Майбутнє вже зараз

Усім вже більш-менш зрозуміло, у якому напрямку розвиваються технології. Підхід до даних стає настільки уніфікований, що їх майже завжди стало можливим розглядати як окрему сутність, безвідносно до проги, якою вони створені. І чим далі дані відходять від свого софта — тим чіткіше стає зрозумілим:

дані завжди повинні бути доступні.

Але і проги завжди повинні бути доступні ТЕЖ!!

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

Дані завжди були нарізно — у вигляді файлів вони зберігались у вас на вінті; що заважає їм зберігатися у вигляді баз даних на вінті у гугла (наприклад)? якщо їхні вінти надійніші, а бази даних — більш уніфікований підхід? З прогами все не так очевидно (зазвичай ви працюєте з локальними клієнтами, які встановлені на вашому компі); але працюючи у вебі, ви постійно стикаєтесь з прогами, які виконуються на серверах (напр. сторінки цього блогу динамічно генеруються з php-коду, виконаного на серваку); а якщо ви користуєтесь веб-додатками типу google docs, то взагалі розумієте, про що я. Але є ще більш радикальний тип “інтернет-програм”: т.зв. rich internet applications (вікіпедія: 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 — екстеншн під іе та файерфокс (підтримка опери очікується…); качається, встановлюється, працює. Як приклад, можна подивитись на Google Reader — після встановлення gears у файерфоксі там з’явиться така стрілочка “офлайн”, коли клікаєш її — на ваш комп скачується база останніх постів (поки що без картинок); надалі ви можете “ходити” по них, читати, відмічати прочитані , взагалі, користуватися усією звичайною функціональністю google reader; і все це офлайн! як тільки ви клікните “онлайн” — усі дані синхронізуються з вашим акаунтом рідера! <- от де уся нехитра фантастика ситуації…

Bottom-line: на одному форумі зустрічав я людину, що мала бажання написати прогу, яка вела би список аніме. Це просто абсолютно класичний приклад для застосування інтернет-додатків. Усі ми знаємо, як це має бути приблизно: MyAnimeList.net. Та правильне рішення для такої проги — це те саме, але як сервіс:

1. можливість не просто працювати зі своїми даними онлайн (як зараз) — але і ОФЛАЙН (типу Google Gears) (я маю мати можливість оновлювати свою базу аніме, навіть находячись офлайн; і коли я виходжу онлайн — база має синхронізуватися!)
2. плюс до цього можливість працювати поза браузером, в окремому вікні (варіант типу AIR)

Навіщо мені знати взагалі — онлайн я чи офлайн? Це має знати прога (чи браузер, в якому я в даний момент працюю) — і вона має автоматично синхронізовувати мене з моїми даними в інтернеті! Різниця між інтернетом і вашим вінтом — суто технічна, формальна; по суті її не існує, і поступово вона зітреться. <- це майбутнє; чи реалізовувати це за допомогою AIR? чи яви? чи більш низькорівнево? — це ваш вибір; головне результат: прога повинна працювати з даними прозоро, незалежно від того, онлайн вона чи офлайн, дані мають бути і тут, і там, і локально, і на вебі — прога, окрім всього іншого, має підтримувати їх у синхронізованому стані. (До речі, локальна база даних як в AIR, так і в Google Gears реалізована на основі sqlite ;-) ).

І розглядати такий підхід до рішення проблеми аніме-списків, наприклад, як у вигляді локальної проги, що працює з локальними даними — це навіть недоречно… Це просто не на часі.

[додано пізніше (14.09.2007)]

• ще приклад з google gears: плагін під wordpress, який вмикає вашому блогу офлайн-функціональність (увага: працює тільки з файерфоксом; тільки для ознайомлення з технологією…).
• швидкий вступ до google gears з того ж сайту.

[/додано пізніше]