Assasin, если честно, то не убедил. Я не виноват.
Основной твой аргумент Расширяемость. Между прочим "Анна Каренина" написана в формате txt.
Неужели не хватит места для ini ?
А в ini, во первых строках (там где Автор), ну никак не возможно добавить информацию о версиях ?
Да хоть сейчас - никаких проблем.

Ответ на пункт 4 - поподробней можно ? Нифига не понятно.

nesco, про БД. Два пальца... Но немного сложней чем с ini.
А тут скорость и не нужна - между установкой компонента и началом соединения точек времени достаточно для прорисовки точек.
------------ Дoбавленo в 18.39:
а что там есть и неоднородные данные ?
------------ Дoбавленo в 18.42:
Создаёшь пять таблиц
[About]
[Type]
[Edit]
[Property]
[Methods]
и вперёд.

Но и бинарных файлов будет столько же, сколько компонентов, и переносится они будут тяжелее, чем одна база
------------ Дoбавленo в 19.11:

Не думаю, что сильно сложнее. База же элементов есть, ее и можно было бы расширить. Можно пойти дальше -- проводим поиск компонента в базе, если не находим, то пытаемся найти in (может быть приставленный компонент). Даже уже существующую базу можно было бы применить для хранения конфигурации, или еще того лучше -- и кода

[offtop]Однако чего вспомнили - описания компонентов в XML![/offtop]

1.
a) XML - это стандарт, хоть и достаточно общий. Если не полениться и написать XLS (XML Schema), то из общего стандарта он превратится в специальный. И если при загрузке xml не забывать загружать схему, то получим автоматическую проверку правильности файла (как синтаксиса, так и структуры).
b) Машинночитаемый - "заточен" под обработку компьютером
с) Поддержка мультиязычности (i18n) встроена в стандарт
2,5. a) XML (несжатый) занимает больше места на диске. Впрочем, диски на терабайт уже далеко не экзотика...
b) Начальная загрузка и разбор XML требуют больше ресурсов (память, процессорное время), чем ini. Но разницу, полагаю, можно будет заметить только на очень старых компьютерах
с) "Трудно редактировать". Ну это ваще... Есть бесплатные редакторы XML-файлов, с подцветкой синтаксиса, с проверкой правильности при сохранении (или по запросу) - это уже удобнее, чем Блокнот, функционал которого не менялся где-то со времён Windows 9x. А если к среде будет прилагаться нормальный редактор компонент (доделанный ECreator), то станет ещё легче
3. a) Человекочитаемый формат
b) Компактный
с) Можно править в блокноте
d) Быстрая загрузка
4. a) Не явялется стандартом
b) Нет простой поддержки мультиязычности (i18n)
6. PROFIT От стандартизации ещё никто не проигрывал.

БД тоже стандартизированы, по крайней мере, запросы к ним
Преимущесто БД -- она идет одним файлом, а не кучей файлов

ИМХО. Самый лучщий вариант -- применение БД на основе быстрых движков, и нафиг никакие XML не нужны. В одной базе можно хранить все, и бинарные данные -- тоже

nesco, а кодоген у нас заточен под бинарный формат ?

Наш -- нет

nesco, но БД ручками нельзя править же! (XML - можно, если умеючи).

nesco, автор создал компонент. Что он должен выкладывать? Всю свою базу компонентов? Или генерить какой-то скрипт, который вытянет из этой базы всё, что касается компонента, а затем загонит в базу конечного пользователя?
Tad, если речь идёт про конфиг компонента, то кодогену плевать на формат файла. Кодогенератор общается со средой через доступные интерфейсы.

БД можно - есть чем тоже.
------------ Дoбавленo в 20.02:
Netspirit, ты не знаешь, как из БД на 6 000 000 записей вытащить одну нужную ? Элементарно.
------------ Дoбавленo в 20.04:
Всю жизнь считал, что кодоген общается с кодом компонента, а не ini

Tad, ручками - это в "Блокноте"

А БД ручками - даже в нашем Sqlite_Demo из примеров к HiAsm-у

Думаю, что пользователю проще всего работать с .ini Потому, что оно проще всего устроено.

А разработчикам HiAsm, вероятно, проще с XML и BD раз об этом ведется серьезный разговор.

Тогда что имелось в виду?

Да че тут думать-то - есть ini читаем ini, нет ini -- леземь в базу. По ПКМ на элементе можно портировать его в базу, все части компонента портируются в базу и удалятся из соответствующих папок. Тогда получится, что у нас плавать в свободном плаввании будут только непортированные компоненты

nesco, согласен