Pull to refresh

Comments 35

UFO just landed and posted this here
UFO just landed and posted this here
В этом фрагменте речь идет только о специфичных проблемах браузерного кэширования. Насколько WKWebVew подходит для других приложений, сейчас не подскажу.
А можно пойти еще дальше и предусмотреть возможность вручную сохранять страницу. Как раз над этими идеями мы сейчас и продолжаем работать.

Аналог Reading List в Safari?
Так вот для чего нужна эта кнопка! А я думал это просто непонятно зачем нужный дубляж закладок :)
Вы можете нажать «Обновить» или перемещаться по истории через «Вперед»/«Назад». Можете тапнуть по ссылке. Можете ввести адрес вручную.

Как идет работа с ресурсами адрес которых может перегенерироваться при обновлении (скажем фрагмент ссылки дописывается с помощью JS)? Или допустим в кэше есть сайт sample.com/, как будет обработана попытка обращения к sample.com/?a=1

Кстати, результаты POST-запросов или исполнения AJAX мы также сохраняем в кэш. Без этого многие динамические сайты выглядели бы в офлайне неполноценно.

Результаты запросов сделанных с использованием Webrtc тоже кэшируются?
Ситуации могут быть разными. Сейчас мы уже учимся распознавать такие ресурсы и подбирать к ним сохраненные в кэше данные. Часть сделали, но еще не успели влить в эту сборку беты.

Про WebRTC интересный вопрос. Специально это не исследовали. Можете подсказать пример, когда это было бы полезно?
Наверное когда вебмастера станут использовать WebRTC и p2p технологии для переноса нагрузки (сеть) с серверов на клиентов. Только вот с позиции кеширования это еще более грустная задача.
А есть какие-либо планы насчет того, чтобы что-то сделать с кэшем на десктопе? Последнее время сталкиваюсь с ситуацией, что ждать ответа из кэша с десктопа приходится дольше(при том что у меня SSD), чем загрузить ту же самую страницу с очищенным кэшем.
Да, думаем над применением технологии кластерного кэширования на десктопе.
Как вариант — использовать Profile sync daemon или что-то аналогичное.
Здорово =) Впоминается эпоха начала 2000-х, когда я заходил через диалап на несколько минут в интернет, чтобы потом по страницам ходить в «автономном режиме» в IE6…
UFO just landed and posted this here
У мобильных и сейчас есть, как правило, если не подключен пакет, например.
Или же Teleport Pro — «Выкачай весь интернет себе в оффлайн» :)
p.s. помню электронную оффлайн версию журнала CHIP на диске бонусом к печатному изданию… вот так был настоящий интернет без интернета…
«Time Machine» для интернета — неплохо!
«Time Machine» для интернета есть скорее здесь.
А это — офлайн кеш (что, впрочем, тоже неплохо, но, увы, не опенсорсно).
Подкину идею предлагать загрузить из кеша, если сервер вернул 40* или 50* http код ответа. Если это еще не сделано.
А вторым номером — возможность раздать/получить кеш страниц по p2p (хотя тут сложно обеспечить как безопасность для раздающего, так и достоверность для получателя).
О, вы делаете то, что работало в Opera версий 7..11?
Сейчас все это делают. В том числе и Опера.
Я как-то упустил момент, а на компьютере-то оно есть/будет?
Планируем применить и на десктопе.
Кстати, еще вот хотел уточнить — а в истории на мобильном браузере как-то будут помечаться те страницы, которые возможно восстановить из кэша?
Таких планов не было, но идею стоит обсудить.
Буду надеяться, что она получит воплощение :-) Т.к. вчера задумался над этим, и понял что с точки зрения пользователя — было бы удобно видеть, какие страницы можно спокойно открыть из кэша, при отсутствии связи, а какие — не стоит даже пытаться.(Насчет десктопа не знаю, там это вроде как излишне… хотя в принципе тоже может имеет смысл, но на мобильных устройствах — я бы обеими руками голосовал за такую фичу)
Будут ли эти наработки в дальнейшем предоставлены сообществу chromium?
Раньше с хедерами no cache, ответы на post не кэшировались и т.п., сейчас кэшируются, т.е. больше записи на диск и объемы, большая часть времени все же онлайн и для редкого оффлайна накладные ресурсы так скажем, на сколько большие?
По нашему опыту могу сказать, что чем дальше доработка от простой оптимизации и багфиксинга, тем сложнее это влить в Chromium. Если в Chromium нет единого продуктового мнения и команды, готовой «пролоббировать» доработку в Chrome (мы ведь все понимаем, что в Chromium попадает только то, что пригодится в Chrome), то результат будет отрицательный. Недавно, например, хотели передать доработанную технологию предзагрузки, но не получилось. С учетом ограниченных ресурсов, стараемся отдавать как можно больше простых доработок, которые попадут в проект быстро и не спровоцируют длительные споры. Хотя некоторые крутые штуки все же получается делать. Например, недавно помогли с новой сборочной системой для Windows и с реализацией HTTP/2.

Что касается дополнительной нагрузки от применения кластерного кэширования, то наше внутреннее тестирование не выявило проблем. Публичное бета-тестирование предоставит нам дополнительные данные, которые тоже будем анализировать.
Очень полезная функция. Ждем портирования и в декстопную версию Яузера.
Раздел «Кэширование качественное» слегка настораживает.

  1. Заходим на свой аккаунт в Gmail с чужого телефона.
  2. Забываем разлогиниться.
  3. Дома вспоминаем об этом и разлогиниваемся удалённо.
  4. Спим спокойно.
  5. Владелец телефона отключается от Интернета и открывает Gmail.
  6. ???

Что произойдёт в шестом пункте? Владелец телефона прочитает все просмотренные письма?
В этом примере важно понять, что пока злоумышленник доберется до 6 пункта, он уже три раза может прочитать Ваши письма.

1. Вы можете и не знать, cтоит ли на конкретном сайте метка no-cache. А если и стояла вчера, не пропадет ли она завтра. Или браузер проигнорирует ее (ошибки бывают у всех). Уже на этом этапе нужно допускать самое обычное кэширование, если работаете с важными данными. И очищать кэш по завершению работы.

2. Если вы забыли выйти из аккаунта, то у злоумышленника уже полно времени на копирование данных из почты без какого-либо кэша.

3. Не рекомендую пользоваться устройством злоумышленника для доступа к личной почте. Он ведь может прослушать ваш трафик или скопировать письма еще во время вашей работы, предусмотрительно установив нужный инструмент на телефон.

Если он не воспользуется этими ситуациями, то письма, действительно, в текущей бете будут открыты в офлайне (только те, что успели загрузиться). Посмотрим, что можно изменить в этой ситуации. Спасибо.
Спасибо за развёрнутый ответ :) То, что этот пример достаточно надуманный, понятно, но всё же в случае с обычным кэшированием третий пункт давал бы какое-никакое спокойствие.
Такое есть и у Opera Mini, и у китайского UC Browser. Но вот всё равно они заразы бывают не могут загрузить страницу из кэша именно в тот момент, когда нет интернета и её хочется прочитать. И никаких настроек размера буфера кэша у них нет. У вас есть?

Хотелось бы и на десктопе так же ограничить потребление памяти, например указать — на весь браузер не более 300Мб, всё что не влезает — в кэш на диск, с сохранением набранных комментариев в формах ( а не как OneTab плагин для Chrome, который стирает набранный текст). И с обязательным профайлингом загрузки, если диск занят чем-то другим и ресурс с диска достаётся дольше чем он скачивался бы заново, то скачивать.
Вы уверены, что именно такое? На Facebook или ВКонтакте можно проверить.

Нет, увеличить лимит кэша сейчас нельзя.
Sign up to leave a comment.