Центр управления для Linux

[B4rr4cuda]

я думаю имелось ввиду настроить пути в конфигах

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

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

[ViTality]

ну модуль может состоять и из нескольких фалов...
к примеру библиотека+файл конфигурации
яж нигде не говорил "1 модуль - 1 файл"

[B4rr4cuda]

Т.е согласен с тем, что вшивать поиск конфигов в код модулей (не их конфигов, а именно библиотек) нецелесообразно?

[Vadim]

B4rr4cuda
Целесообразно для настройки какой-либо выдающейся программы, например squid'а. Ведь, если здраво посмотреть, я squid то могу себе и не ставить, так что и конфигурировать его из основного модуля мне незачем. А вот если поставил, то подключаю модуль для его конфигурации и там уже должен быть поиск.

[B4rr4cuda]

Так я и веду к тому, что нужно вынести поиск за пределы модуля (библиотеки), не включая в ЦУ (в цу могут быть хелперы), а вынеся в скрипты, конфиги и тд.
Так, чтобы правка путей не требовала правки кода и перекомпиляции.
Да, для сложных случаев в модуле может быть собственный поиск, но используемый, как дополнительный и управляемый конфигом либо скриптами модуля.

[Vadim]

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

[FedeX]

...и чего вы тут треплетесь, флудеры) Аффтар вроде ужо давно на это забил

[B4rr4cuda]

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

Ну а я о чем талдычу уже вторую страницу? Вынести поиск из модуля!

Что я предлагаю: сам ЦУ, по запросу модуля, предоставляет путь к конфигу.
А вот, как он это сделает - тут уже много вариантов:....

Скрипты, предоставляемые модулем, тоже должны исполняться в ЦУ, а не модулями или standalone. По команде из скрипта, когда путь к конфигу уже найден, ЦУ вызывает из модуля заранее определенную процедуру с путем в качестве параметра. Фактически скрипты будут выполнять функции этой, вынесенной в отдельную либу, процедуры поиска, только более универсально.

...и чего вы тут треплетесь, флудеры) Аффтар вроде ужо давно на это забил

Не результат важен, а процесс! Да и "аффтар" вроде как не постоялец, а так - заглядывает иногда. Так что думаю заглянет и почитает наши "потоки сознания"...

[minoshi]

...и чего вы тут треплетесь, флудеры) Аффтар вроде ужо давно на это забил

Не результат важен, а процесс! :lol: Да и "аффтар" вроде как не постоялец, а так - заглядывает иногда. Так что думаю заглянет и почитает наши "потоки сознания"... :wink:

и читаю с БОЛЬШИМ вниманием

ОК, сделаем так. Вместе с ЦУ будет библиотека, реализующая поиск конфигурационного файла (назовем его getinfo.so - название универсальное, т.к. возможно нам в будущем потребуется еще каки-нить функции, все они лягут сюда). Поиск будет предусматривать поиск по двум схемам - назовем их классический и полный. В классическом - поиск будет идти только по определенным папкам (/etc, usr/etc - список в разработке). В папках mnt, sbin, bin, media и т.п. искать конфиги нет смысла - т.к. в них согласно логике linux конфиги быть не должны (по крайней мере так пишут авторы книг о линуксе).
Полный поиск соответственно прочешет весь диск. Что будет разработчик модуля делать с результатом поиска -хранить его в инишке, xml или не хранить его вообще - дело самого разработчика. Впрочем он может им вообще не пользоваться :)

[alexs]

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

[minoshi]

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

добавь еще одну копейку :) - а формат библиотеки? текстовый файл со списком путей?

[alexs]

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

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

[Vadim]

фактически да - только с указанием дистра.

Тогда зачем этот текстовый файл звать "библиотека"?
От этого путаница (по крайней мере у меня в голове). Я привык, что "библиотека" - это *.so или *.dll.

[alexs]

Я привык, что "библиотека" - это *.so или *.dll.

Библиотека файлов - кофигов.

И ещё - многие конфигурируемые параметры можно вынести также в текстовые файлы - т.е. реализовать файл описания структуры параметра (тип параметра, приложение где он используется, обязательность парамтера, описание параметра) - а уж морда конфигурилки будет собирать по этим файлам интерфес.

[Vadim]

Библиотека файлов - кофигов.

О! Вот это другое дело. Извилины в мозгу сразу распутались и стали прямыми, как железная дорога Санкт-Петербург - Москва. Теперь всё понятно.