Если делать альтернативу 1С, то какие брать готовые компоненты?

[trdm]

Я тут просматривал quickjs. В принципе вешь годная, много лишнего, но можно и поотсекать.
Само собой "слегка" русифициировать.
Qt-шники к нему присматриваются. Есть задел под дебугер.
Есть модули и прочее.
Что думаете?

[Злоп]

Я не в теме, но сначала порешать какой движок БД, транзакции, блокировки и многопользовательский режим...?
По мне так внешний вид 77 вполне устраивает, если туда хорошее автомасштабирование форм и типа подобноее - то мне норм ;-) Делать второй снеговик по сложности языка, и прочей хрени - как-то мне представляется малоперспективным

[Forum123]

> Если делать альтернативу 1С, то какие брать готовые компоненты?

Для меня так самый важный вопрос - "Какой движок будет использован для хранения данных?".

[Djelf]

Для меня так самый важный вопрос - "Какой движок будет использован для хранения данных?".

Для клиент-серверных баз ИМХО PostgreSQL, для мелких баз можно и SQLite (хотя SQLite может работать с очень большими базами), в локальном/терминальном режиме (ни в коем случае не в сетевом, возможно повреждение базы) потому что диалект SQLite в большей степени соответствует PostgreSQL, чем остальным диалектам SQL.
Если не выпендриваться с запросами, будет работать без изменений и там и сям.
SQLite будет быстрее PostgreSQL в таком сценарии использования.
Свой движок файловой базы данных изобретать, как это сделала 1С в 8ке, это немыслимый хардкор.

[Forum123]

SQLite будет быстрее PostgreSQL в таком сценарии использования.

Вы профи по SQLite.
Годится ли она для многопользовательской работы, есть ли в ней недостатки.  ...?
Какую функциональность невозможно реализовать на SQLite, которая имеется в 1С 7.7 или 1С 8.x?

[Forum123]

Для клиент-серверных баз ИМХО PostgreSQL, для мелких баз можно и SQLite (

Это суждение навеяло мысль.
Лучше PostgreSQL использовать.

Первоочередные задачи:
 - разработать архитектуру хранения метаданных и реализовать;
 - аналогично для данных;
 - GUI для работы с метаданными и данными.

[Forum123]

Первоочередные задачи:

Тем кто откажется разрабатывать 1С 7.8 - отключим газ.

ИМХО вполне реально скопом (человек пять) разработать а-ля 1С 7.7.
Предлагаю использовать harbour.
В нём реализовано API, которое позволяет работать с любыми источниками данных.
Для Postgress без проблем можно разработать API для движка.
Виртуальная машина имеется и весьма эффективна.
Вот с чем нужно будет повозить так это разработка API для индексов.
В harbour API есть, но ИМХО не годится для а-ля 1С.

[Forum123]

Предлагаю использовать harbour.

API Harbour использовал и с его core знаком.
Помогу.

Кстати ЯП один и тот же для всех источников данных и можно одновременно использовать сколько угодно источников данных.
Проект десятилетиями тестировался.
Без проблем можно API разработать и для нынешей 1С 7.7.
Почему не сделал?
Потому что ныне разрабатываемое API годится для любого типа задач и много функциональней чем любая СУБД.

Для разработки а-ля 1С harbour годится.

[Forum123]

Для разработки а-ля 1С harbour годится.

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

[trdm]

1. Для клиент-серверных баз ИМХО PostgreSQL,
2. для мелких баз можно и SQLite (хотя SQLite может работать с очень большими базами), в локальном/терминальном режиме (ни в коем случае не в сетевом, возможно повреждение базы) потому что диалект SQLite в большей степени соответствует PostgreSQL, чем остальным диалектам SQL.
3. Если не выпендриваться с запросами, будет работать без изменений и там и сям.
SQLite будет быстрее PostgreSQL в таком сценарии использования.

1. а с какого релиза начинать и какую сборку использовать?
2. А можно и не париться и взять тот же codebase, добавив драйвер SQlite для запросов. по типу 1sqlite. и получится у нас нормармальные скульные запросы к БД.

[Forum123]

2. А можно и не париться и взять тот же codebase, добавив драйвер SQlite для запросов. по типу 1sqlite. и получится у нас нормармальные скульные запросы к БД.

Не для спора.
Harbour по существу а-ля Foxpro 2.6 и core не хуже codebase.
В ЯП harbour и ООП имеется, замыкание, даже сишный код в исходники добавлять можно.
Кстати API 1C 7.7 не сложно разработать.

Это обсуждение возможности разработки а-ля 1С.
Ждём новых предложений форумчан.
Вообщем то а-ля 1С можно скопом разработать.
Пусть Альф за главного будет.
Его задача - разработка GUI.

Профи на форуме много ...

[trdm]

Пусть Альф за главного будет.

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

[trdm]

По мне так внешний вид 77 вполне устраивает, если туда хорошее автомасштабирование форм и типа подобноее - то мне норм ;-) Делать второй снеговик по сложности языка, и прочей хрени - как-то мне представляется малоперспективным

ну да. 8 конечно хорошо, но некоторые места я так и не понял.
к примеру в модуле объектов документ:

Код Выделить Развернуть

Движения.регистрТакойто.Записывать = Истина:
запись = Движения.регистрТакойто.Добавить();
запись.отрибут = значение;
....

и в какой момент это добавляется?
не проще слелать запись.Записать();

[Djelf]

Я не могу сказать какие камни встретятся на пути, sqlite за последние 10 лет невероятно мощьно бустанулось, в частности была исправлена ее многолетняя фишка - отсутствие right join и т.д. и т.п.
А размер dll то почти и не вырос! Меньше метра, это фантастика для SQL базы.
Некоторые казусы видимо придется исправлять наступанием на швабру, причем не один раз.
Формат базы стабильный, API не меняется, т.е. движок можно обновлять еще очень долго, без особых проблем, просто заменой одной dll.

[Злоп]

Мое основное участие - попкорн и кола, так как далек от настоящего программирования ;-)
Потестить/поюзать, что-то пописать типа прикладных конф может даже.
Но как создание очередного "убивца 1С" - прикладные конфы ГДЕ? КТО? в противном случае - это так, хобби... поиграться... (типа как я WMS на клюшках пишу когда желание есть... а его все меньше, ибо потребителей нет...)