[Devel-conf] alterator и его требования (was описание структуры бакенда на примере пользователей)

Stanislav Ievlev =?iso-8859-1?q?stanislav=2Eievlev_=CE=C1_gmail=2Ecom?=
Чт Окт 18 14:39:11 MSD 2007


18.10.07, Vitaly Ostanin<vyt на altlinux.org> написал(а):
>
> Проблемы есть с созданием бакендов, с документацией для этого.
> Все эти врапперы для вывода текста, зависания при забытых '()',
> когда вывод не нужен...
Да есть такое ...

С документацией проблемы я насколько это возможно уже решил.
А вылечить забытые '()' я надеюсь при помощи "IDL", то есть
автоматической генерации собственно части отвечающей за протокол.

Проблему stdout это конечно не вылечит, но нет ничего идеального ;)

>
> > Они практически без
> > изменений живут вот уже несколько лет и большинство пользователей
> > устраивают за небольшими исключениями как-то:
> > хотелось бы добавить типизацию и иметь некоторое декларативное
> > описание структуры бакенда (это собственно и обсуждается)
> >
> > Вторая задача иметь возможность этому же гипотетическому админу также
> > легко и без проблем строить к своему бакенду интерфейс и интегрировать
> > его в общую среду управления. Крайне желательно чтобы человек сразу
> > получал интерфейс и графический и http.
>
> Так как насчёт ACL ? Независимо от выбранного способа надо
> определиться, нужно это или нет. Схема работы только от рута
> сильно урезает применимость конструктора.
ACL тоже нужны. Можно добавить в список.
>
> > Вот с этим проблема. Уже много спобобов было перепробованно - не один
> > не показал себя с лучшей стороны. Главная проблема: какую-бы
> > обалденную модель, view и controller мы не придумали. На выходе
> > хочется получать "гибкий и отзывчивый" интерфейс. То есть меньше чем
> > на MacOSX мы (то есть руководители) не согласны ;)
> >
> > А отсюда получается, что при описании интерфейса так или иначе
> > возникает  не слабое программирование. Единственное до чего я сейчас
> > дозрел - что это программирование надо вести на JavaScript - понятный
> > большинству людей язык программирования.
> >
> > Кроме того проблема: GUI и WUI очень сильно отличаются.
>
> Что такое WUI ?
Web UI

> > Последние мои мысли тут - отказаться от сферического коня. Сделать
> > акцент на http.
>
> Надо определиться, устраивают ли бакенды без хранения состояния
> (как они есть сейчас). Если устраивают, почему бы действительно
> не остановиться на одном http ?
Сейчас все бакенды с хранением состояния. Без хранения состояния в
отдельных случаях не возможно - слишком большие тормоза.
Я бы на http остановился, но пользователи почему-то не хотят.

>
> В итоге делать модули будут всё равно программисты.

Вот это и печально. Но порог вхождения нужно снижать по максимуму.

> > Никогда не скрывалось, это писалось как хак ибо не успевали с
> > http-интерфейсом (QuiX и qooxdoo оба провалились;) ).
>
> Почему провалились? qooxdoo выглядит симпатично, используется в
> samba4. Может, как-то не так пробовали?
Это были последствия сферического коня, а именно неудачного layout.
Если делать layout "под-qooxdoo", будет работать нормально  ... но в
qt наоборот станет хуже ;)


Подробная информация о списке рассылки devel-conf