[Devel-conf] web-only морда?

[Michael Shigorin]

On Thu, Oct 18, 2007 at 11:39:08AM +0400, Stanislav Ievlev wrote:
> Это должен быть построитель решений на базе дистрибутивов ALT Linux.
> Пользоваться этим конструктором должен быть в состоянии пользователь
> не владеющий глубокими познаниями в программировании, зато прекрасно
> понимающий свои админские задачи и умеющий решать их при помощи
> известных средств автоматизации, включая shell.

Designer навроде того, что ты описывал (но который мне уже не
довелось посмотреть в действии) -- оченно бы помог именно таким.

> С бакендами в общем-то проблем никаких нет. Они практически без
> изменений живут вот уже несколько лет и большинство
> пользователей устраивают за небольшими исключениями как-то:
> хотелось бы добавить типизацию и иметь некоторое декларативное
> описание структуры бакенда (это собственно и обсуждается)

Я ещё завёл (и по мере наличия возможности насаждаю ;) привычку
не засовывать всю логику в backend, а по возможности делать
скрипт, пригодный для CLI-использования без рефлекторных навыков
запуска бэкендов.  Бишь имеющий --help и внятные опции.  
Или оформлять как control facility, если оно ближе.

Такая себе либификация.

> Вторая задача иметь возможность этому же гипотетическому админу
> также легко и без проблем строить к своему бакенду интерфейс и
> интегрировать его в общую среду управления. Крайне желательно
> чтобы человек сразу получал интерфейс и графический и http.

Угу.

> А отсюда получается, что при описании интерфейса так или иначе
> возникает  не слабое программирование. Единственное до чего я
> сейчас дозрел - что это программирование надо вести на
> JavaScript - понятный большинству людей язык программирования.

Уфф... чгря тому же мне lisp-like с введением и примерами как-то
ближе оказался, но мож просто потому, что на js давно даже
мелочей не делал, а с lisp когда-то и начинал изучение
программирования.

В любом разе очень хорошо, если получится не вываливать "сразу
всё" в случае, когда достаточно сделать просто: я бы не стал
писать services, если бы представлял, во что оно захочет
вылиться, если подумать, как оно _на самом деле_ должно выглядеть
и работать :)  А так хоть как-то делало и предоставляло
возможность делать улучшения поверх или переписать нафиг,
но уже представляя практические недостатки.

> Кроме того проблема: GUI и WUI очень сильно отличаются.
> Настолько сильно, что хоть M хоть V хоть C, невозможно сделать
> систему одинаково хорошую и для первого и для второго.

Не надо делать "одинаково" хорошую.  Стоит делать _достаточно_
хорошую для основной функциональности, а в остальном высовывать
особенности фронтэнда в качестве возможности задать хинты,
которые вполне могут быть специфичными.  Шлифовка общая,
полировка в индивидуальном порядке.  Простые вещи сделать просто,
сложные -- возможно.  (какую бы ещё поговорку присобачить ;)

Сравнивая свои .scm с вон письмом Большакова -- думаю, что это
было в неплохой степени достигнуто, хотя провоцируя сваливать 
и интерфейс, и действия в одну кучу на манер PHP.

> Есть способ задействовать мощные средства Ajax типа QuiX или
> qooxdoo и сымитировать GUI , но на этом проблемы не
> заканчиваются. layout отличается настолько, что либо в конечном
> итоге вы напишете свой web-браузер на qt либо всё будет
> тормозить на web.

BTW в qt4 же скоро будет webkit.  Судя по owb, вполне прилично
ездит, хотя с ajax до gecko ему далековато.  Пакет так до сих пор
и не добит, болванка здесь:

http://fly.osdn.org.ua/~mike/RPM/SRPMS/owb-0-alt1.20070720.src.rpm

-- сборка обломается, но из buildroot его можно запустить так:

LD_LIBRARY_PATH=. ./owb http://www.ajaxdaddy.com

(для оценки того, на чём молча обломается, а что работает)

> Последние мои мысли тут - отказаться от сферического коня.
> Сделать акцент на http. Последние продвижения на ниве Ajax
> позволяют сделать гибкий интерфейс, а наличие плагинов к
> браузерам позволяет сделать фокусы которые раньше были возможны
> только для gui (например посмотрите модуль настройки x11 и xkb
> в desktop 4.0).

Возможно и так.  Если писать будет разумно.  Возможно, это
закрывает и консольный вариант с учётом fb, а вот без fb у нас
пока остаётся или выразительный ssh+$EDITOR, или невыразительные
попытки чего-то полноэкранного начудить.

> Из неудобных вещей в fbi я знаю только:
> 1. необходимость писать workflow на scheme - это не для всех
> пользователей возможно.  Есть наработки чтобы писать всё это на
> Javacsript в модели DOM - это должно быть доступно всем.

Никак не всем, скорее веб-девелоперам.  Выбирая те или иные
ограничения, ты выбираешь в любом разе _ограничения_, а не
"всех".

BTW удивительно, как не проводилась массированная реклама
alterator среди русскоязычных пользователей emacs. ;)
(сам по мере возможности иным подсовывал)

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----       Oct 26--27, Kiev, Ukraine:
--       http://conference.osdn.org.ua