Короткие интервалы пригодятся, если надо обработать кучу данных, не повесив при этом браузер – разбить обработку на части и вызывать очередную итерацию через эти самые интервалы.
Например, как тут: http://alljs.ru/articles/timeout/fast-settimeout.
Ну вот, живое подтверждение неправильного маркетинга (или как там это правильно назвать?).
Дело ведь не в циферках версий (строгую проверку уже давно отключили – большинство расширений теперь считаются совместимыми, пока не доказано обратное), а в изменении различных API.
А ведь всего-то надо реже вносить критические правки, которые могут сломать расширения – в большинстве случаев это не должно мешать добавлению очередных фишек HTML/CSS.
Да и реклама нужна, причем рекламировать надо уникальные особенности, а это как раз расширяемость вдоль и поперек.
Да, это тоже проблема.
Обычно-то просят подобное для экономии трафика – то есть большое отрезать.
А тут если только еще и начало данных получать. Если, конечно, информация о размере в начале идет.
Так вообще бессмысленно затея выглядит.
Честно говоря, это лучше у автора Adblock Plus и спросить.
Лично мне кажется (я специально не разбирался), что решение о блокировке запроса надо принимать синхронно. Выглядит, во всяком случае, оно именно так, но Adblock Plus все-таки штука сложная, могу и ошибаться.
А тут надо послать серверу запрос и дождаться ответа.
Да еще и синхронный nsIChannel.open() мало того, что не рекомендуют, так еще и пишут, что он может быть не реализован вообще. Конечно, можно сделать синхронную обертку вокруг асинхронного кода, но это будет еще медленнее…
Блокироваться (по идее, опять же) должно еще до начала каких бы то ни было запросов, так что никакого ответа от сервера у нас, скорее всего, еще не будет – то есть без запроса не обойтись.
Ну, и надо понимать, что это дополнительный трафик будет, так что насколько это получится оправдано в конечном счете – еще вопрос.
Есть и другая польза: можно быстро проверить, как выглядит сайт для незалогиненного посетителя. И можно зайти под двумя аккаунтами, например, на почту.
Хотя за этим больше к Multifox'у. Другое дело, что встроенный механизм явно должен работать надежнее.
Верните мое лицо! ©
Удобство, впрочем, то еще. :)
Например, как тут: http://alljs.ru/articles/timeout/fast-settimeout.
Впрочем, следует ли из этого повышение качества – еще увидим. :)
Жаль, конечно, что не получилось успеть до релиза Firefox 20, но у меня не получается так быстро, как у некоторых.
Дело ведь не в циферках версий (строгую проверку уже давно отключили – большинство расширений теперь считаются совместимыми, пока не доказано обратное), а в изменении различных API.
А ведь всего-то надо реже вносить критические правки, которые могут сломать расширения – в большинстве случаев это не должно мешать добавлению очередных фишек HTML/CSS.
Да и реклама нужна, причем рекламировать надо уникальные особенности, а это как раз расширяемость вдоль и поперек.
Обычно-то просят подобное для экономии трафика – то есть большое отрезать.
А тут если только еще и начало данных получать. Если, конечно, информация о размере в начале идет.
Так вообще бессмысленно затея выглядит.
Лично мне кажется (я специально не разбирался), что решение о блокировке запроса надо принимать синхронно. Выглядит, во всяком случае, оно именно так, но Adblock Plus все-таки штука сложная, могу и ошибаться.
А тут надо послать серверу запрос и дождаться ответа.
Да еще и синхронный nsIChannel.open() мало того, что не рекомендуют, так еще и пишут, что он может быть не реализован вообще. Конечно, можно сделать синхронную обертку вокруг асинхронного кода, но это будет еще медленнее…
Блокироваться (по идее, опять же) должно еще до начала каких бы то ни было запросов, так что никакого ответа от сервера у нас, скорее всего, еще не будет – то есть без запроса не обойтись.
Ну, и надо понимать, что это дополнительный трафик будет, так что насколько это получится оправдано в конечном счете – еще вопрос.
Хотя за этим больше к Multifox'у. Другое дело, что встроенный механизм явно должен работать надежнее.
А то в Firefox & Co только вот такое работает:
Но удобный for each...in все равно хотят убрать. :(