Есть идея

[Elrock2]

Я понемногу начал писать программу типа 1С.
Примерный план.
Минимум зависимостей. Использование только открытых технологий.

1. GUI на Qt4.

2. База данных на PostgresSQL.

3. Язык программирования Ruby. Большие плюсы - Полное ООП, динамическое программирование, перегрузка операторов, большое количество уже готовых библиотек, легкое расширение средствами C/C++. В последнее время значительно набирает обороты.

4. Конфигурация в файлах на XML (средствами Qt).

5. Возможность обмена данными между программами через XML-RPC.

6. Система клиент-серверная: тонкий клиент - сервер приложений.


Пока пишу сервер приложений.

Пишите на skmproject@gmail.com

[Hoblin]

Я понемногу начал писать программу типа 1С.

В одиночку? Вы представляете, сколько времени писали 1С и сколько времени это потребовало? Вряд ли Вы найдёте здесь что-то, кроме скептицизма.
В любом случае, удачи!

А что должна будет делать система в первую очередь? На какие задачи ориентирована?

[Goodvin]

Я понемногу начал писать программу типа 1С.

А Вы на самом деле профессионально разбираетесь в бухгалтерском, финансовом и кадровом учёте ?
Ну как минимум, хотя бы.

6. Система клиент-серверная: тонкий клиент - сервер приложений.

Ну вообще-то, строго говоря, Вы путаете желтое с горьким.
В сложившейся терминологии на сегодня есть вот такая "загогулина":
Клиент-серверная арзхитектура - это когда есть клиент и сервер.
А наличие сервера приложений характеризует архитектуру как трёхуровневую/трёхзвенную, то бишь "клиент" <=> "сервер приложений (Application Server)" <=> собственно сам "сервер" (в большинстве случаев это сервер БД).
Примерно вот так.

[Elrock2]

А Вы на самом деле профессионально разбираетесь в бухгалтерском, финансовом и кадровом учёте ?
Ну как минимум, хотя бы.

Зарабатываю внедрением 1С уже 12 лет. Есть опыт внедрения в небольших организациях где-то 600-800 сотрудников, 5-8 бухгалтеров.
Бухгалтерский учет знаю на уровне гл.бухгалтера (жизнь заставила) - сам веду учет в своей фирме. Расчет зарплаты тоже.

Насчет того сколько писала 1С свою платформу.
1. 1С писала все с нуля. Почитайте описание встроенного языка 1С. 80% процентов его почти никогда не используется.
2. Не нужно создавать клон 1С. Там кроме очевидных достоинств есть недостатки.

Подробнее обсуждали здесь. http://forum.posix.ru/viewtopic.php?id=843

[Skull]

Насчет того сколько писала 1С свою платформу.
1. 1С писала все с нуля. Почитайте описание встроенного языка 1С. 80% процентов его почти никогда не используется.

У 1С был штат программистов, многолетний опыт, армия внедренцев и каналы связи с регламентирующими органами. У вас пока нет ничего из вышеперечисленного.

2. Не нужно создавать клон 1С. Там кроме очевидных достоинств есть недостатки.

Безусловно. Но неужели было сложно посмотреть уже начатые проекты, оценить их, связаться с руководителями, чтобы не набивать шишек? Я, к примеру, как руководитель проекта E/AS готов к сотрудничеству. Главный вопрос: готовы ли вы сами к обсуждению платформы и, самое главное, к её поддержке и развитию? Не будет ли это увлекательное кодерство на пару-тройку месяцев, после чего интерес иссякнет?

[Elrock2]

У меня ощущение, что все проекты изначально замахиваются слишком на многое. Не нужно ставить перед собой нереальные цели. Я убежденный сторонник использования простых стандартных технологий и не изобретения велосипедов. GUI лучше и быстрее писать на Qt, т.к. это на данный момент лучшая по моему мнению библиотека. Тем более клиентская часть без проблем должна работать и на Windows. Зачем сочинять собственный язык программирования или тянуть какой либо экзотический, когда Ruby способен почти не все, а по гибкости и применению изощренных приемов почти как C++. Единственный его недостаток - нет поддержки Unicode (обещают добавить в новых версиях), но пока нормально и с CP1251.Ни к чему пытаться охватить все базы данных, раз PostgresSQL есть в каждом дистрибутиве, и гораздо лучше особенно в плане локализации, чем MySQL.
Сначала данные я пытался между клиентом и сервером по протоколу XML-RPC, потом выяснил, что нет нормальной библиотеки, зато если и сервер писать на Qt, то можно использовать внутренний переносимый формат в которрый можно упаковывать различные типы данных, в том числе и сложные - массивы и структуры.
На данном этапе пока написаны базовые классы для взаимодействия по сети.

[Skull]

У меня ощущение, что все проекты изначально замахиваются слишком на многое. Не нужно ставить перед собой нереальные цели.

Без этого не сделать нормальную платформу. Можно сделать единичное решение, которое не получит распространение.

Я убежденный сторонник использования простых стандартных технологий и не изобретения велосипедов.

«Простые стандартные технологии» для учётной платформы — это J2EE и сервера приложений типа JBoss. Проблема в том, что мало народа из сообщества потянет разработку на них.

Зачем сочинять собственный язык программирования или тянуть какой либо экзотический,

Затем, что на местах эту платформу будут дорабатывать низкоквалифицированные кодеры.

...когда Ruby способен почти не все, а по гибкости и применению изощренных приемов почти как C++.

На нём очень мало программистов и, как следствие, мало наработанного инструментария.

Единственный его недостаток - нет поддержки Unicode (обещают добавить в новых версиях), но пока нормально и с CP1251.

Поверьте — сегодня это ненормально. Это была одна из причин, почему я отказался от CLIP.

Ни к чему пытаться охватить все базы данных, раз PostgresSQL есть в каждом дистрибутиве, и гораздо лучше особенно в плане локализации, чем MySQL.

Для учётной платформы РСУБД использовать напрямую — самоубийство при расширении. Да и зачем локализация для СУБД? Связи-то и, как следствие, километровые запросы, никуда не денутся.

На данном этапе пока написаны базовые классы для взаимодействия по сети.

Значит, готово 0,5% от всей платформы. Какие планы дальше?

P.S. Прошу прощения за резкость, просто это реально серьёзный вопрос. Вы готовы к обсуждению архитектуры или как?

[trdm]

Весна, чего поделаешь )))
Можно взглянуть на ТЗ?
Второй раз спрашиваю, междупрочим...

[DjSpike]

Эх-х-х-х.... Не смог пройди мимо...
Я плохо разбираюсь в программировании. Но единственное что смог использовать для своих целей это "Ананас". Хотя он и очень далек до полноценного инструмента, но это единственное что сейчас можно использовать для учета в Linux.. Если такие талантливые программисты как trdm , Skull и Elrock2 не тратили свои силы на создание новых проектов, а помогли бы развитию Ананаса уже давно бы была нормальная учетная система... Знаете басню Крылова "Лебедь, рак и щука" вот такая ситуация сейчас и у Вас... P.S. Ananas написан на Qt3, было две попытки портировать его на Qt4, чем они закончились я не знаю.... Чего мне не хватает в Ананасе ??? Сейчас пожалуй только одного, то что в справочника автоматически не увеличивается поле "Код" и нет возможности визуально переносить из групп в группы (хотя опять таки обидно один человек это сделал, но не хочет присылать патч чтобы его код включили в cvs)... ОБИДНО!!!!

[Elrock2]

«Простые стандартные технологии» для учётной платформы — это J2EE и сервера приложений типа JBoss. Проблема в том, что мало народа из сообщества потянет разработку на них.

Стандартная технология - это входящая в состав практически любого дистрибутива. К Qt, Ruby,PostgreSQL это относится, а вот к JBoss - нет. И вообще переносимость Qt весьма на высоте, тем более в состав программы, если уж это очень понадобится можно включить скомпилированную версию Qt с урезанием в процессе компиляции ненужного функционала. С большой долей вероятности будет работать без перекомпиляции на большом количестве дистрибутивов.

Затем, что на местах эту платформу будут дорабатывать низкоквалифицированные кодеры.

Упаси нас господь от кодеров! По опыту работы в 1С я убедился что в 99% процентах (в основном это касается зарплаты) пытаются программировать от незнания, что того же самого можно добиться правильной настройкой программы. Помнится в одной фирме программисты начал писать код для расчета районного коэффициента, в итоге все поползло по швам, хотя и нужно было в одном окне проставить коэффициент 1.15. В случае бухгалтерского учета - за всю жизнь мне пришлось всего лишь 2 раза переделывать конфигурацию, т.к. это были филиалы крупных фирм где сверху навязывали свои требования, с моей точки зрения, абсолютно не оправданные, т.к. того же самого эффекта можно было добиться грамотным использованием уже имеющегося аналитического учета. Хотя я по глупости поначалу пытался программировать, учитывая интересы полуграмотных или не в меру продвинутых бухгалтеров. Легче подстроить свой учет под программу, чем наоборот. А пытаться слепо автоматизировать уже имеющийся бумажный учет (в том числе и на Excel), где чаще всего хаос - идиотизм. Получаем автоматизированный хаос.

На нём очень мало программистов и, как следствие, мало наработанного инструментария.

Ruby сейчас на подъеме, в основном из-за среды веб-разработки Ruby-On-Rails. Есть даже http://www.rubyonrails.ru/.
И еще - это настоящий 100% объектно-ориентированный язык, простой в изучении, но с замечательными прибамбасами - определение типов на этапе выполнения, динамического программирования, когда можно переопределять даже встроенные классы и даже объекты, что идеально для встраивания в приложения. Написание новых классов для него на C/C++ гораздо проще чем, к примеру на Python.

Поверьте — сегодня это ненормально. Это была одна из причин, почему я отказался от CLIP.

Qt все обрабатывает в Unicode, хотя может экспортировать/импортировать и из других кодировок встроенными средствами. Кажется в версии 1.9, уже вышедшей, Unicode внедрили. На подходе 2.0.

Для учётной платформы РСУБД использовать напрямую — самоубийство при расширении. Да и зачем локализация для СУБД? Связи-то и, как следствие, километровые запросы, никуда не денутся.

Использовать запросы напрямую не планируется. Будет как в 1С и Ананас.

Сейчас зарегистрировал сайт. В ближайшие дни там будет более развернутое описание. По мере готовности будет выкладываться исходный код.

[Hoblin]

Если такие талантливые программисты как trdm , Skull и Elrock2 не тратили свои силы на создание новых проектов, а помогли бы развитию Ананаса уже давно бы была нормальная учетная система...

Вот не нужно только заявлений про уникальность Ананаса в каждой теме, "и DjSpike пророк его...". Успешность проектов зависит не только от талантливых программистов, но в первую очередь от грамотного управления проектом. Если из всех проектов хотя бы парочка доживёт до своей реализации - то это уже здорово.

[DjSpike]

Я ничего не упоминал про уникальность Ананаса, просто то что хочет сделать Elrock2 уже реализовано в Ананасе. Кроме того это не просто пустая программа, У Ананаса есть свой сайт, есть система регистрации ошибок (Mantis), есть Форум и Wiki. Т.е. все что нужно для полноценного проекта.

1. GUI на Qt4.

Ананас написан на Qt3 , но как я упоминал выше были уже две попытки его портировать на Qt4.

2. База данных на PostgresSQL.

Ананас работает сейчас с двумя базами: MySQL, PostgreSQL. Я на форуме предлагал еще включить поддержку Firebird....

3. Язык программирования Ruby. Большие плюсы - Полное ООП, динамическое программирование, перегрузка операторов, большое количество уже готовых библиотек, легкое расширение средствами C/C++. В последнее время значительно набирает обороты.

Сейчас в Ананасе используется Qsa-script.

4. Конфигурация в файлах на XML (средствами Qt).

Конфигурация в Ананасе хранится в xml.

Код: Выделить всё

<?xml version = '1.0' encoding = 'UTF-8'?>
<!DOCTYPE ananas_configuration SYSTEM "ananas-cfg.dtd">
<ananas_configuration>
    <info>
        <name>Оперативный учет.</name>
        <lastid>1535</lastid>
        <author>Проект Ананас</author>
        <date>2007-12-27</date>
        <remark>Типовая бизнес-схема позволяет вести учет поступления и реализации товара, получать данные об остатках товара на любую дату. Просматривать движение товара в требуемые промежутки времени, в разрезе требуемых контрагентов. Оформлять банковские, кассовые документы.  Формирует печатные формы документов и отчеты в форматах Microsoft Office и OpenOffice.org.</remark>
        <dir>inventory</dir>
    </info>
    <interface>
        <toolbars>
            <toolbar id="718" name="New tool bar" >
                <command id="723" name="Журнал счетов" >
                    <description id="724" />
                    <menutext id="725" />
                    <key id="726" />
                    <comaction>1336</comaction>
                </command>

5. Возможность обмена данными между программами через XML-RPC.

На форуме народ уже обкатал обработки для выгрузки и загрузки через xml...

[Juliette]

Уважаемый DjSpike, давайте мы всё-таки будем учитывать тот нелёгкий для вас факт, что изначально это тема уважаемого Elrock2, и предоставим слово-таки ему. Он вполне толково и как раз по делу отписывается.
Хорошо? Иначе мне придётся вас (в очередной раз) вежливо попросить из темы.

[trdm]

(0) А какова вообще целевая аудитория проекта?
Кто они пользователи твоей программы?

[Skull]

Если такие талантливые программисты как trdm , Skull и Elrock2 не тратили свои силы на создание новых проектов, а помогли бы развитию Ананаса уже давно бы была нормальная учетная система...

При всём моём уважении к Андрею Паскалю, Ананас делается, к сожалению, кусочно-заплаточным методом.

Чего мне не хватает в Ананасе ??? Сейчас пожалуй только одного, то что в справочника автоматически не увеличивается поле "Код" и нет возможности визуально переносить из групп в группы (хотя опять таки обидно один человек это сделал, но не хочет присылать патч чтобы его код включили в cvs)... ОБИДНО!!!!

Вот это по мелочи, а обидно. А представьте, что будет, когда я спрошу про
- нормальную трёхзвенку
- компонентной конфигурации
- репозитории готовых компонентов
?

P.S. Генеральный директор одной из компаний сказал, что на создание полноценной свободной учётной платформы потребуется 1 год и 2-4 млн. рублей. Хотя это не учитывает разработку и поддержку конфигурации.

[Elrock2]

Весьма смущают в Ананасе некоторые особенности.

QSA. Использование какого либо распространенного языка имеет большие плюсы. Во-первых экономия времени на разработку и сопровождение, т.е. приходим уже на все готовое. Во вторых большое количество наработанного материала. Для Ruby написано большое количество пакетов, есть собственный репозитарий, менеджер пакетов RubyGems и сообщество разработчиков на http://www.ruby-forge.org. У меня в дистрибутиве Mandriva 2008 несколько десятков библиотек для Ruby. Есть достаточно информации, в том числе и на русском языке.

Отчеты через OpenOffice. Кроме лишних зависимостей и увеличения системных требований нет возможности использовать чрезвычайно удобное свойство как в 1С, когда из отчета можно добраться щелчками мыши до документов-источников. Кроме того, судя по описанию,и примерам, поставляемым с Qt, написание отчетов в ней не очень сложно. Есть даже готовые разработки генераторов отчетов, откуда можно взять исходный код.

Недостаточно учтен опыт конкурентов, в частности 1С. Ее можно сколько угодно ругать, но это стандарт де-факто, а по удобству использованию вообще вне конкуренции. Все попытки умельцев "сделать лучше чем 1C", прислушиваясь к людям "с большим опытом работы", привели к фактической деградации до уровня жалкого подобия БЭСТа или Паруса и "вечной бета-версии". Впрочем подробности можете прочитать здесь в моей статье: http://citkit.ru/articles/621/

[Skull]

Стандартная технология - это входящая в состав практически любого дистрибутива. К Qt, Ruby,PostgreSQL это относится, а вот к JBoss - нет.

Нет, стандартной технология становится, когда принята сообществом, её активно использует большое число народа и потому есть обучение, поддержка, решения (в том числе и для разработчиков).

Упаси нас господь от кодеров!

Зря вы так. Для успешного распространения на местах как раз и нужны низкоквалифицированные внедренцы, которых нужно заинтересовать в продукте. Они на этом деньги делают, а перед разработчиками ставят задачи и обеспечивают обратную связь.

Ruby сейчас на подъеме, в основном из-за среды веб-разработки Ruby-On-Rails.

Увы, его распиаренность сейчас падает, так и не достигнув популярности Perl, Python и PHP.

Qt все обрабатывает в Unicode, хотя может экспортировать/импортировать и из других кодировок встроенными средствами. Кажется в версии 1.9, уже вышедшей, Unicode внедрили. На подходе 2.0.

А на чём будет описываться бизнес-логика? Я это писал как претензию Ruby.

Использовать запросы напрямую не планируется. Будет как в 1С и Ананас.

Там всё же сервер приложений не окончательно выделен.

Сейчас зарегистрировал сайт. В ближайшие дни там будет более развернутое описание. По мере готовности будет выкладываться исходный код.

А адрес?

[Elrock2]

Кто они пользователи твоей программы?

Программа должна быть для обыкновенного бухгалтера, со знаниями не большими, чем для 1С. Не нужно перекладывать на пользователя свои проблемы. Я уже 12 лет занимаюсь обучением пользователей и сопровождением программ 1С и понимаю, что разрешать пользователю низкоуровневые операции, т.е. стремится к всемерной настраиваемости - гибель. Таких опытов я уже насмотрелся. Все равно рядовой пользователь не разберется и наделает ошибок.

Программа скорее поначалу должна быть ориентирована на малый/средний бизнес, которые могут позволить себе стандартизировать учет а не идти на поводу у горе-аудиторов, которые формируют учетную политику, пригодную скорее для бумажного учета, но сложную и неэффективную для компьютерного.

Скоро подготовлю более полное техническое задание и выставлю на ваше обсуждение. Рад выслушать все предложения. Чем больше людей будет принимать участие в проекте, чем лучше.

Можно писать на skmproject@gmail.com
Есть сайт http://skmproject.my1.ru, пока пустой на днях выложу материалы.

[DjSpike]

Уважаемый DjSpike, давайте мы всё-таки будем учитывать тот нелёгкий для вас факт, что изначально это тема уважаемого Elrock2, и предоставим слово-таки ему. Он вполне толково и как раз по делу отписывается.
Хорошо? Иначе мне придётся вас (в очередной раз) вежливо попросить из темы.

Уважаемая Juliette давайте будем учитывать тот факт, что каждый имеет право голоса, и если Вы внимательно читаете то я как раз по теме и пишу, а не то что мне взбредет в голову....

[Juliette]

Уважаемая

Juliette

давайте будем учитывать тот факт, что каждый имеет право голоса, и если Вы внимательно читаете то я как раз по теме и пишу, а не то что мне взбредет в голову....

Уважаемый DjSpike, давайте тогда будем считать, что вы в данной теме уже успели изложить всё, что требовала ситуация. Дальнейшее выяснение вопроса можно перенести в личку.

[Elrock2]

Зря вы так. Для успешного распространения на местах как раз и нужны низкоквалифицированные внедренцы, которых нужно заинтересовать в продукте. Они на этом деньги делают, а перед разработчиками ставят задачи и обеспечивают обратную связь.

По своему опыту с 1С могу сказать - что главная выгода от ее Конфигуратора - не возможность писать кое-что самому, а возможность самостоятельно устранять ошибки программистов 1С. К примеру в Зарплате и Кадрах я уже много лет во все новые конфигурации вношу несколько одних и тех же исправлений и только тогда ставлю клиентам.
Если для программы нужны программисты внедренцы - то это плохая программа. Нужно только обучение пользователей, чем я по сути в большей мере и занимаюсь. Раньше все силы уходили на удовлетворение экзотических потребностей бухгалтеров. Сейчас я в 90% могу доказать что их потребности от лукавого и обязательно выйдут боком.

[trdm]

Кто они пользователи твоей программы?

Программа должна быть для обыкновенного бухгалтера, со знаниями не большими, чем для 1С....

По моим наблюдениям наши проекты пересекаются в 25% заявленного, есть общие "фронты" работ. Можно посотрудничать.
Стукнись пожалуйста в аську (308-779-620), хочу тебя немного поругать и похвалить, здесь это недопустимо.

[Skull]

Есть сайт http://skmproject.my1.ru, пока пустой на днях выложу материалы.

Пожалуйста, сообщите о том, что доступны материалы на этом сайте в этой теме. Плюс к этому крайне желательны Wiki и список рассылки.

[trdm]

Вот это по мелочи, а обидно. А представьте, что будет, когда я спрошу про
- нормальную трёхзвенку
- компонентной конфигурации
- репозитории готовых компонентов
?
P.S. Генеральный директор одной из компаний сказал, что на создание полноценной свободной учётной платформы потребуется 1 год и 2-4 млн. рублей. Хотя это не учитывает разработку и поддержку конфигурации.

У Вас батенька аппетит слишком большой.
Перечисленные Вами вещи далеко не всегда восстребованы, и вообще гармонично
их скрестить можно только ведя разработку системы на языках низкокого уровня.
А для автоматизации бизнеса в рамках бухгалтерского и управленческого учета чаще
приходится читать ПБУ и микроэкономику чем учебник по С++ или шарпу. Так что
вышеописанная компонентная нарезка скорее вредна для внедренцев чем необходима.
Внедренцам в этой сфере скорее подойдет среда с плотносопряженными и хорошо
подобранными и адаптированными к друг другу объектами, желательно небольшого состава.

И вообще говорить о "правильности" архитектуры конкретной
системы без вводных параметров о её использовании я считаю
очень непрофессиональным подходом.

Чего мне не хватает в Ананасе ??? Сейчас пожалуй только одного, то что в справочника автоматически не увеличивается поле "Код"

Это элементарная функция, которая реализуется маленьким и быстрым параметризованным запросом. Если упрощенно.

нет возможности визуально переносить из групп в группы

Это ваша плата за за универсализм.
И еще, это одна из ГРОМАДНОГО числа возможностей которые вам прийдетс
делать руками, и это еще цветочки.

[Skull]

Вот это по мелочи, а обидно. А представьте, что будет, когда я спрошу про
- нормальную трёхзвенку
- компонентной конфигурации
- репозитории готовых компонентов
?
P.S. Генеральный директор одной из компаний сказал, что на создание полноценной свободной учётной платформы потребуется 1 год и 2-4 млн. рублей. Хотя это не учитывает разработку и поддержку конфигурации.

У Вас батенька аппетит слишком большой.

Не у меня. Это оценки людей, которые имеют достаточный опыт.

Так что
вышеописанная компонентная нарезка скорее вредна для внедренцев чем необходима.

Безусловно. Это резко снижает потребность с велосипедах местных внедренцев, когда они берут большие деньги за знание того, как бороться с костылями 1С.

Внедренцам в этой сфере скорее подойдет среда с плотносопряженными и хорошо
подобранными и адаптированными к друг другу объектами, желательно небольшого состава.

При росте сложности системы и потребностей в адаптации монолитная конфигурация становится весьма проблемным местом. Плюс к этому при обновлении конфигурации и API потребуются значительные усилия по адаптации изменений. Это хорошо для внедренца — у него есть козыри для дойки клиента. Но счастлив ли клиент?

И вообще говорить о "правильности" архитектуры конкретной
системы без вводных параметров о её использовании я считаю
очень непрофессиональным подходом.

А кто тут обсуждает конкретную систему?

[DjSpike]

Это элементарная функция, которая реализуется маленьким и быстрым параметризованным запросом. Если упрощенно.

Продемонстрируйте свой талант, исходники Ананаса можно взять здесь ftp://leaderit.ru/pub/ananas/nbfiles/ или здесь http://www.leaderit.ru/cgi-bin/cvsweb.cgi/ananas/

Или Вы можете только языком трепать ?????

[trdm]

Продемонстрируйте свой талант, исходники Ананаса можно взять здесь ftp://leaderit.ru/pub/ananas/nbfiles/ или здесь http://www.leaderit.ru/cgi-bin/cvsweb.cgi/ananas/
Или Вы можете только языком трепать ?????

Опять провокации?
Работа тут не трудная, разбираться много прийдется.
Только смысла не вижу. Тебе это не поможет.
Я тут покопался на ананасовском форуме на предмет твоих постов/скилов,
хотел понять с кем я имею дело, показал твои постинги ребятам из отдела..
короче ржали все, но не дого правда... рабочий люд что поделаешь...
резуме по тебе говориь не буду, ибо забанят.
Но резюме было единогласное....
А по поводу ананаса, если тебе память отшибло, могу опять процетировать то что я говорил уже, причем неоднократно:
Ананас меня как разработчика не устраивает. Ни по внутренней архитектуре, ни по структуре.
Да и ребята мои смотрели, говорят не айс, не нравится.
То есть смысла нет в принцыпе что-то делать, если фундамент не устраивает, никакой косметический ремонт не поможет..

[trdm]

И вообще говорить о "правильности" архитектуры конкретной
системы без вводных параметров о её использовании я считаю
очень непрофессиональным подходом.

А кто тут обсуждает конкретную систему?

Вот тут и зря, программинг точная наука. Никто никогда не пишет абстрактных программ. Все пишут конкретные программы. Под конкретные условия и с конкретными целями...
А насчет велосипедов могу опять повторить: их изобретают постоянно и ничего зазорного в этом не вижу.
Руби, питон, перл, сквирел, луа, JS - все это велосипеды. Жизнь от этого хуже стала? Неа, у каждой марки нашлись почитатели в силу какой-то причины, стройности синтаксиса, упорядоченности кода, мощности языка.. Это все тотже велосипед - интерпретируемый скрипт... И что что я изобратаю велосипед например? Следуя вашей логике по одной дороге что должен пройти только один человек, а если пойдет другой то позор на всю жизнь?
Короче надо похоронить понятие "изобретать велосипед" как несостоятельное.
А кто еще к нему обратиться буду считать догматиком )))

[Olegator]

давайте подождём пока Elrock2 напишет спецификацию, тогда и будет что обсуждать. тем более что у Elrock2 есть опыт работы в этой сфере, может что и дельное получится

[Elrock2]

Опубликована Приблизительная спецификация. Жду предложений.