Packaging on the web

15 января 2015 W3C опубликовал новый драфт (First Public Working Draft) предметно раскрывающий перспективы слияния digital publishing’а (далее dp) с глобальной сетью — Packaging on the web. Почему хочу остановиться на нем подробнее: дело в том, что это революционная в том числе и для всего процесса веб-разработки технологическая спецификация.

Современный веб построен на том, что HTML-код, «подтягивает» кучу внешних относительно себя ресурсов, определенных в нем, сопутствующем CSS, javascript и тп, где вышеозвученное — тоже внешние ресурсы. Например, в спецификации отмечается, что сайт http://www.bbc.co.uk «тащит» за собой более 160 файлов при загрузке первой страницы. Именно эту проблему и призвана решить данная спецификация. В спецификации предлагается упаковывать такие множественные ресурсы в один архив и подключать в <link> (только один из случаев использования, остальные ниже) HTML-документа. Соответственно, такой пакет определяет область видимости, для обращения к ресурсам внутри него. Также описывается, каким образом организовывается кэширование и описание этих ресурсов.

Сеть становится все более модульной. Web-components предоставляют единый системный подход к постоянно используемым элементам: контролы по умолчанию для выбора дат (datepicker), галереи (carousel) и нативная поддержка табов. Эти компоненты, описаные через HTML, JS, CSS, также нуждаются во внешних ресурсах — изображениях, данных и тп. Одновременно  модули ES6 Modules [ECMASCRIPT] будут позволять создавать взаимосвязанные файлы значительно меньшего размера.

Почему это так важно: многие сайты предоставляют не просто контент, они по сути являются самостоятельными  приложениями. При таком подходе, они должны иметь пакетную (packages) структуру ресурсов, которые могут быть машинным образом протестированы и подписаны. Пакеты могут включать как сами данные, так и контент. Именно поэтому эта спецификация рассматривается в dp как потенциальный фундамент реализации EPUB-WEB: цифровые публикации EPUB 3 представляют собой данные и метаданные упакованные в zip-архив. Архивирование здесь предполагает упаковку всего сайта или его частей в бандлы, которые легко отслеживать системам кэширования.

Кроме того, существуют и другие форматы packaging’а:

  • Packaged Web Apps (Widgets)
  • Open Container Format
  • Dataset Publishing Language
  • Tabular Data Package
  • Mozilla Archive Format
  • MHTML (RFC 2557)
  • Webarchive format
  • WARC

Основная часть из них основана на zip и имеет три основных недостатка:

  • Zip позволяет поточную передачу (streamable), но с определенными оговорками. Запись центральной директории (central directory record), в которой перечислены валидные файлы внутри архива, находится в конце zip-архива. Вполне можно использовать per-Entry имена файлов, но возможны конфликты с центральной записью.
  • Плохая управляемость. Например, порядок файлов в архиве может быть критичным, а обычно упаковка архива происходит средствами встроенными в ОС пользователя, которые не дают контроля над порядком упаковки.
  • Ограниченность метаданных. В формате zip существует механизм предоставления дополнительной информации о файле через дополнительные поля (extra fields). Однако, их обычно недостаточно. Каждое такое дополнительное поле представляет собой пару ключ-значение: двухбайтовый ID и двухбайтовое же значение. Список core и расширенных кодов ID доступен в секциях 4.5 и 4.6 определения zip. При этом заголовок файла, который включает эти метаданные не должен превышать 64кб.

В спецификации предпринята как раз попытка описать совершенно новый формат, который не имеет этих ограничений.

О преимуществах и фичах

  • Пакеты могут быть использованы для создания и контроля кэша ассоциированного с множественными URL без создания множественных запросов. Что позволит снизить проблемы, связанные со скоростью отклика в разных асинхронных запросах, особенно для клиентов и серверов, которые не поддерживают SPDY или HTTP/2 (где есть поддержка упаковки множества ресурсов в один HTTP-ответ).
  • Установка веб-приложений через специальные сторы и прямо из сети. Спецификация дает четкое определение, каким образом это реализуется. Вы скачиваете приложение и устанавливаете его на свой десктоп или ноутбук. Разрешаете выполнение и используете апп в оффлайне.
  • Распространение библиотек: по сути packaging может использоваться как распределенная пакетная система библиотек типа npm. Если есть сложная композитная библиотека, то, вероятнее всего, он будет состоять из нескольких зависимых библиотек, а здесь сразу появляется необходимость контроля зависимостей,  версионности и прочее.
  • Поточность. Предлагается определить как подтип Streamable Package Format (SPF) с media type application/package.
  • Fragment Identifiers. Схема идентификатора фрагмента может быть использована для определения части пакета и фрагмента такой части. Определен синтаксис, каким образом обращаться к элементам пакета через URI (главным образом, # как реализация поверх имеющейся системы адресации).
  • Безопасность: SPF может содержать скрипты, поэтому все, что находится в пакете должно подчиняться тем же правилам, как если бы было вызвано по отдельности.
  • Сжатие и организация архива. Сжатие может быть полным, либо частичным (часть архива). Единого стандарта организации не предлагается, но приводится возможный пример для стэндалон веб-аппа:
    • главная страница (root page)
    • скрипты настройки и инит-данные
    • стили
    • шрифты
    • лого и фоновая графика
    • отложенные скрипты
    • графика контента
    • вторичные HTML-страницы
    • другие вторичные ресурсы для использования только на этих HTML-страницах
  • Встраивание: помимо запросов с определенными спецификацией HTTP-заголовками, может быть встраивание через link, либо просто <a>. Например:
    <a href="editor.gzip" rel="package" scope="/">download this application</a>
  • <link rel="package" href="http://example.org/exampleWidget.zip" type="application/widget">

    Область видимости при этом определяется параметром scope, определяющим, что все ресурсы, начинающиеся с символа «/», могут быть найдены в пакте editor.zip.

  • Регистрация типа application/package в IESG и дальнейшая подача в IANA в media type registry в соответствии с [RFC6838].
  • Аналогичная же процедура для регистрации нового типа  link в Registry of Link Relations в соответствии с [RFC5988]