nesco, я же не зря писал, что в 10 раз длиннее.
В общем, я старый и уже перестаю понимать ход мыслей молодёжи.

Tad, более правильно было бы писать:

[offtop]nesco, хе, круто смотриться код со смайликами [/offtop]

Это формат для сугубо машинной обработки. Любят его, наверное, объектно ориентированные программисты - фанаты фреймворков и готовых XML-движков разного толка, включая различные реализации AJAX. И используется он часто как транспортный формат. Я к тому и написал это, что если бы всё в среде было на XML, тогда было бы логично его применение. Но это не так. По крайней мере, в настоящий момент.

Я против XML, и против множества версий элементов.

Но, я за прилинковку исходников компонентов, использованных в схеме, к Sha-файлу.
Это серьезный шаг к совместимости, на сегодняшний день, все остальное, это мелкие удобства.

[offtop]я даже с SVN не обновляюсь, потому, что боюсь потом что-то, где-то, не запустится из моих готовых схем.
А еще я храню туеву-хучу папок установленного HiAsm для некоторых проэктов.
А еще я храню целые виртуальные машины VMWARE, с Hiasm настроенными под определенные проэкты. Это бред. Элементы должны переноситься.[/offtop]

login, те ты предлагаешь создавать, к примеру, временную вкладку дополнительных компонентов на момент загрузки схемы с прилинкованными компонентами, после выгрузки схемы, эти компоненты будут удаляться из этой вкладки, так

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

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

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

nesco, правая кнопка по компоненту, "Установить" - и правь себе сколько хочешь. Затем опять - "Внедрить в схему". Или вообще жесть - правой кнопкой "Править код/конфиг" прямо в схеме...

Я предлагал полуавтоматически делать установку -- после перетаскивания временного компонента в нужную вкладку, выдается запрос "Установить", если отвечается "Да", компонент устанавливается в среду, иначе -- возвращается на свое место во временной вкладке

Итак, пожалуй, начну. Для начала хочется уточнить следующий момент:

Теперь вопросы:

1. Повышается расширяемость конфига, он становится способен впитывать в себя больше типов информации, расширяется область применения (например, очень удобно им представлять версии).
2. Недостаток всем очевиден - размер файла растет, читаемость - падает. Глупо это отрицать.
3. Делаешь такой формат, какой захочешь, делаешь максимально удобным его для нужд, очень расширяем.
4. Нету строго ограниченного формата - рано или поздно будет конфликт версий.
5. В расширяемости.
6. Расширяемость

Быстродействие загрузки -- падает с увеличением числа компонентов из-за дополнительного парсирования. Хотя, возможно, и не очень сильно.
А вот заменить ini на базу данных, вот это была тема. Доступ к полям базы производиться быстрее, чем доступ к ini файлам

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