Локальное хранилище в Opera

UPD: Свершилось! В каракане (Опера 10.50) будет родное хранилище. Так что, если Вам не нужна обратная совместимость, просто подождите немного.
Люблю Оперу, черт возьми!

Далее следует оригинальный текст.

Кстати, при помощи window.postMessage можно организовать-таки локальное хранилище данных в замечательном браузере Opera. Касается это, разумеется, только юзерскриптов.

Приведу методику без примера:

1. Юзерскрипт устанавливает обработчик "message", заранее.
2. Юзерскрипт ждет, пока у документа станет доступным document.body.
   Насколько я понял, для этого достаточно запустить код при помощи setTimeout({{code}}, 0) — выполнение потока быдет отложено до окончания обработки всех юзерскриптов, а там уже и document.body подоспеет.
   Но это особо не тестировано, и на это лучше не полагаться.
3. Юзерскрипт добавляет в документ iframe с display: none, ставя в качестве src "file://localhost.myApplicationName" (имя после точки может быть любым).
   Каждый из таких адресов (хоть "localhost.myApplicationName.42") будет считаться отдельным хостом, и для каждого из них можно задать cookie суммарным размером около 50 кб
4. Тот же самый юзерскрипт, будучи запущен в ифрейме, отправляет своему родителю через postMessage содержимое куки.
5. Юзерскрипт в родителе принимает сообщение и далее делает что-то полезное с полученными данными. Или отсылает запрос на другой локальный «хост», если данных недостаточно.

А теперь минусы:

1. Тогда получается, что вообще любой скрипт может получить данные с локального хоста, зная адрес страницы-раздатчика кук.

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

   Второй — прицеплять обрабочик не window.addEventListener("message", …), а window.opera.addEventListener("BeforeEvent.message", …), и в случае, если сообщение пришло с локального хоста, не пропускать его дальше.

2. Данные из «хранилища» приходят асинхронно. А посему придется задержать выполнение основного скрипта до прибытия этих данных.

Методика страшновата, и использует как минимум один хак (и один проприетарный метод, в случае window.opera). Но, в целом, это уже значительно лучше хранения конфигов в куках самого сайта.

Кстати, можно повернуть всю схему и в обратную сторону.
Т.е., заходя на file://localhost.myApplicationName, мы попадаем на некую страницу настройки (document.body.innerHTML по DOMContentLoaded еще никто не отменял ), откуда открываем другой хоств iframe с определенным (оччень секретным) параметром, на котором уже поджидает «засланный казачок» и прописывает в куки определенное значение. Например, что юзерскрипт не следует запускать на этом домене, а вместо этого выходить после первой же проверки, экономя ресурсы.

В общем, применений масса. Любители пользовательского скриптописания для оперы — дерзайте! Надеюсь, Вам пригодится этот текст.