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 <[EMAIL PROTECTED]> ------ Linux.Kiev http://www.linux.kiev.ua/ ---- Oct 26--27, Kiev, Ukraine: -- http://conference.osdn.org.ua _______________________________________________ devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
