вначале были форумы, и на форумах были аватары. Потом появились блоги, и комментаторы хотели иметь там аватары. Но загружать аватар на каждый блог было неудобно, и явился Gravatar. На нём можно было указать свой емейл, загрузить аватар, и он автоматически появлялся рядом с твоими комментариями на всех блогах с поддержкой этой системы.
это было намного удобнее, чем прежде, но недостаточно хорошо, потому что это была централизованная система. Всё завязано на единый сайт, и если с ним что-то случится, или он задумает сменить бизнес-модель, будет неловко. Распределённые системы в этом смысле лучше. Тут под рукой удачно оказался OpenID, который был распределённый, и у каждого пользователя была своя страничка. Что может быть очевиднее, чем дать на этой страничке ссылку на аватар? Так появился pavatar.
однако у pavatar были недостатки по сравнению с gravatar. Во-первых, пользователи без OpenID, с одним только емейлом, оставались не у дел. Во-вторых, разбор HTML-страницы, чтобы извлечь из неё ссылку на pavatar, — довольно затратный процесс, и это особенно заметно при большом числе комментаторов. Нужен какой-то другой способ совместить распределённость с простотой.
и вот Libravatar взял идею Gravatar «имя картинки — это хеш от емейла», развил её до «имя картинки — это хеш от емейла или OpenID», а распределённость сделал через SRV-запись в DNS. При этом сервера самого Libravatar служат в качестве запасного варианта. Ну и код Libravatar открытый.
этот вариант более совершенный, хотя и более сложный для умеренно-продвинутого пользователя: вместо вставки тега в код, нужно создать SRV-запись в DNS. Но мне он больше нравится, так что в дополнение к строчке на своей странице:
_avatars._tcp.arty.name. 86400 IN SRV 0 0 80 arty.name.
и скопировал 1344467.png в md5('me@arty.name') = ad4f3a81155f469603be3b8bd5cf3348 и sha256('http://arty.name') = 3876b8005186bddc104495cd6c81f160f990f7fec7e96d89cfd185668bc2886d в корневом каталоге сайта, в соответствии с API Libravatar. Когда в проверялке Libravatar очнётся кеш, она должна начать показывать мой аватар по емейлу и OpenID.
я всё ещё пользуюсь Open Google Reader и не собираюсь с него никуда уходить, но одна из его способностей со временем обесценилась в ноль. Для комментариев в нём по-прежнему используется сервер гугла, на котором сейчас уже никто из моих друзей ничего не комментирует.
без обратной связи уныло, и в конце концов я отступился от решения давать поменьше своего контента и рекомендаций большим братьям. Копия у меня сохраняется на будущее, а собрать систему комментирования, которая через rss и прочие препоны дотянется браузеров друзей, мне слабо. Поэтому буду шарить не только в ридер и свой rss, но и в гуглоплюс с фейсбуком.
попытавшись это дело автоматизировать, я обнаружил те самые препоны. Большие братья не хотят, чтобы роботы насовывали в их сервера контент без участия юзера, отказались потреблять rss, и теперь хотят действий пользователя. Поэтому теперь при рекомендации чего-либо через ридер у меня будут появляться две дополнительные кнопки, открывающие попапы для поста в гуглоплюс и фейсбук. Наверное, вскоре я научу свой браузер действовать там без моего участия, но пока что буду делать это ручками.
забавно, что при изготовлении обеих этих кнопок я вначале попытался использовать продвинутые JavaScript API братьев, но ни одно из них не дало мне нужной функциональности. Гуглоплюсовая кнопка не даёт шарить, пока не поставишь плюсик, а попап даёт. А фейсбуковский API захотел от меня AppID, для которого пришлось ещё и дать ему свой номер телефона, и в конце концов отказался шарить произвольные ссылки, каналья. Пришлось тоже использовать попап. А телефон-то уже не сотрёшь.
в общем, сейчас потестирую перепосты на этой записи, а попозже и выложу изменения в репозиторий.
в недавнем обсуждении с Костей мы поняли, что простое и удобное средство для создания собственных ярлыков приложений не так-то просто найти в системе. Однако оно есть, у него вполне человеческий GUI, и вроде бы оно даже ставится по умолчанию.
встречайте «Main Menu»! Достаточно запустить его, нажать «New Item», заполнить очевидные поля в диалоговом окне — и готово! Этот ярлык уже можно найти поиском в Unity и добавить в панель приложений. Если же Main Menu не установлено в вашей системе по умолчанию, то в Software Center его можно найти ещё и под именем alacarte.
оно, конечно, не появляется в контекстном меню любой папки, но согласитесь, задача создать собственный ярлык приложения крайне редко встаёт перед простым пользователем
предыдущий пост настроил меня на антиутопические сценарии, и сейчас я придумал очередной.
постепенное сближение приложений и веб-сайтов в итоге может привести и к тому, что у веб-сайтов появятся свои лицензии (в виде оферт, например), которые будут содержать, в том числе, и запрет на дизассемблирование и изучение исходного кода оных.
сейчас я порой думаю «хаха», когда простейшими средствами узнаю адрес аудио- или видео-файла, чтобы скачать его себе, а не слушать/смотреть на вебсайте с рекламой, но довольно скоро это может стать противозаконным. «Хакер скачал фильм с нетфликса и раздал голодным», ага.
и тогда будет уже недалеко до признания подобных умений потенциально общественно-опасными, лицензирования деятельности, и прочего контроля. Вполне возможно, что копирасты выберут именно этот путь, раз уж открытые стандарты не особенно торопятся поддерживать их запросы про DRM.
FSF, Столмен и сочувствующие наверняка будут поддерживать сеть сайтов без таких ограничений, но это будет интересно только тем, кто что-то умеет. А если эта деятельность лицензируется, то таких будет очень мало.
обычно браузеры ставят перед собой только общие задачи, и пытаются решать только их. Этот подход уже показал свои качества в случае с кешем, поэтому для надёжного сохранения необходимых ресурсов дополнительно изобрели cache.manifest. Аналогично куки показали своё неудобство для аутентификации, и теперь мозилловцы пробуют правильно обработать этот особый случай в своей Person'ой.
идея в том, чтобы единожды подтвердить свой емейл браузеру, и он надёжно сохранит эту информацию у себя в специальном хранилище. Потом сайты будут запрашивать её у браузера, а он будет выдавать её, с разрешения пользователя. Для безопасной работы там всюду криптографические подтверждения, так что про эту часть можно не волноваться. А раз провайдер емейла в процессе участвует только единожды, на этапе регистрации, то и для него всё становится проще.
к сожалению, массовый юзер имеет только емейл, поэтому непосредственная идея OpenID не прижилась. К ней пришлось придумывать дополнительные штуки типа «у ней внутре неонка URL, но провайдер пользователю его не покажет, он спросит логин и пароль». А это привело к nascar-панелям с иконками провайдеров и посторонним сервисам аутентификации.
если же Persona приживётся, то довольно скоро она столкнётся с проблемой пользователей без емейлов. В некоторых социальных сетях уже можно регистрироваться без емейла, и они будут продвигать специальные API для авторизации через себя. А потом нахлынут бедные африканско-азиатские пользователи, которых аутентифицировать можно вообще только по номеру телефона. Будет интересно.