1.1. Ситуация: еду в метро, читаю ньюсы с телефона. Что-то поменял — удалил пару фидов, добавил ещё один из клипборда. Подъехали к станции — мобилка подцепилась к 3G и отправила всю пачку. Сервер ответил, мобилка к этому моменту уже уехала в туннель. Пофиг: все команды ушли, сервер должен был выполнить.
1.1.1. Допустим, мы посылаем их по одной. Тогда какую-то часть мобилка может успеть послать, какую-то — нет. Ей придётся это учитывать, не только в том, что перепосылать, но и в том, что показывать юзеру.
1.1.2. Посылать отдельные команды можно только последовательно. Допустим, мы добавляем фид командой add-source, и стрим, чтобы его читать — командой add-stream. Сервер имеет право присвоить собственный id этому фиду, вместо того, который предлагает клиент. Значит, вторую команду можно посылать только после выполнения первой, причём, если мы не успели поймать ответ сервера, придётся перечитать конфигурацию и как-то выцепить в ней id только что добавленного фида (по URL, видимо), а затем добавить в команду add-stream.
1.2. Автоматизация проще. Скажем, у меня написан маленький тул, который из opml делает поток команд. Значит, я просто делаю ./opml < subscriptions.opml | curl -nk https://migmit.info/personalfeed/entrypoint --data-binary @- и всё — все подписки из OPML отправляются на сервер. Если делать отдельными командами — мне придётся делать цикл, причём, опять-таки, довольно сложный, учитывая, что следующая команда может зависеть от id, присвоенного сервером сорцу из предыдущей.
2. Джаваскрипт, ИМХО, не пойдёт.
2.1. Тьюринг-полный язык вообще не к месту. Нам нафиг не надо, чтобы сервер ушёл в бесконечный цикл посреди запроса. И вообще, такие программы придётся отлаживать, а как? Нельзя же вешать на админа сервера обязанность ловить глюки в пользовательских скриптах.
2.2. Стандарт ECMAScript гораздо длиннее этого драфта. Во всех реализациях есть какие-то мелкие особенности, которые приходится учитывать веб-программистам. Нафиг нам нагружать разработчиков клиентов ещё и этим?
2.3. Бенефиты не очевидны. Единственный, который я могу с ходу назвать — какие-то "умные стримы", например, тот же стрим, выдающий все непрочитанные посты из всех фидов (и автоматически апдейтящийся при добавлении нового фида). ИМХО, такие вещи лучше реализовать один раз на сервере, либо дать какой-то дополнительный интерфейс для создания этих штук. В конце концов, это опциональная фича, разработчик сервера не обязан её поддерживать.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2013-05-18 08:29 am (UTC)1.1. Ситуация: еду в метро, читаю ньюсы с телефона. Что-то поменял — удалил пару фидов, добавил ещё один из клипборда. Подъехали к станции — мобилка подцепилась к 3G и отправила всю пачку. Сервер ответил, мобилка к этому моменту уже уехала в туннель. Пофиг: все команды ушли, сервер должен был выполнить.
1.1.1. Допустим, мы посылаем их по одной. Тогда какую-то часть мобилка может успеть послать, какую-то — нет. Ей придётся это учитывать, не только в том, что перепосылать, но и в том, что показывать юзеру.
1.1.2. Посылать отдельные команды можно только последовательно. Допустим, мы добавляем фид командой add-source, и стрим, чтобы его читать — командой add-stream. Сервер имеет право присвоить собственный id этому фиду, вместо того, который предлагает клиент. Значит, вторую команду можно посылать только после выполнения первой, причём, если мы не успели поймать ответ сервера, придётся перечитать конфигурацию и как-то выцепить в ней id только что добавленного фида (по URL, видимо), а затем добавить в команду add-stream.
1.2. Автоматизация проще. Скажем, у меня написан маленький тул, который из opml делает поток команд. Значит, я просто делаю
./opml < subscriptions.opml | curl -nk https://migmit.info/personalfeed/entrypoint --data-binary @-и всё — все подписки из OPML отправляются на сервер. Если делать отдельными командами — мне придётся делать цикл, причём, опять-таки, довольно сложный, учитывая, что следующая команда может зависеть от id, присвоенного сервером сорцу из предыдущей.2. Джаваскрипт, ИМХО, не пойдёт.
2.1. Тьюринг-полный язык вообще не к месту. Нам нафиг не надо, чтобы сервер ушёл в бесконечный цикл посреди запроса. И вообще, такие программы придётся отлаживать, а как? Нельзя же вешать на админа сервера обязанность ловить глюки в пользовательских скриптах.
2.2. Стандарт ECMAScript гораздо длиннее этого драфта. Во всех реализациях есть какие-то мелкие особенности, которые приходится учитывать веб-программистам. Нафиг нам нагружать разработчиков клиентов ещё и этим?
2.3. Бенефиты не очевидны. Единственный, который я могу с ходу назвать — какие-то "умные стримы", например, тот же стрим, выдающий все непрочитанные посты из всех фидов (и автоматически апдейтящийся при добавлении нового фида). ИМХО, такие вещи лучше реализовать один раз на сервере, либо дать какой-то дополнительный интерфейс для создания этих штук. В конце концов, это опциональная фича, разработчик сервера не обязан её поддерживать.