Обсуждение и предложения по реализации базы данных проб оборудования

[neobht]

И json здесь вроде бы вообще не нужен. У меня складывается ощущение, что вы не понимаете блок-схему и почему все нарисовано именно так, а не иначе (и написано пусть и с ошибками, но именно так, как написано).

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

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

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

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

[sb]

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

А зачем использовать базу без веб морды ? Какой в этом практический смысл ?
PS Андрей, как часто там используется json на packages.altlinux.org, есть ли такая статистика ?

[sb]

Единственный нюанс, который все же хотелось бы уяснить (выяснить).

Да, похоже в этом нет необходимости. Это просто параметр, показывающий необходимость того, что в пробе содержится оборудование, которого в списке базы нет и его следует туда добавить. С этим определились. Теперь, собственно, надо определиться вот с чем http://vk.com/topic-667081_33389536?offset=80

[Skull]

2sb: доступ к p a.o только у icesk. И, если бы не было под рукой сервера с зеркалом, ходил бы по json.

[neobht]

Единственный нюанс, который все же хотелось бы уяснить (выяснить).

Да, похоже в этом нет необходимости. Это просто параметр, показывающий необходимость того, что в пробе содержится оборудование, которого в списке базы нет и его следует туда добавить. С этим определились. Теперь, собственно, надо определиться вот с чем http://vk.com/topic-667081_33389536?offset=80

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

Это конечно теоретически красивая штука, но на практике для одной категории дистрибутивов, в частности Альт - это с пушки по воробьям. И если вы готовы были написать обработку файлов и строк самостоятельно, вместо sqlite, то мой граф и подграфы - это уже из серии использования postgresql для этой задачи.

[sb]

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

Вы говорите весьма непонятные для меня вещи. Поэтому я и говорю, что скуль оставьте для тех случаев, где оно действительно нужно и целесообразно его использовать. Здесь же (при работе со строками) разберется и новичок (достаточно навыка по чтению help или man).

Это конечно теоретически красивая штука, но на практике для одной категории дистрибутивов, в частности Альт - это с пушки по воробьям.

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

[neobht]

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

[sb]

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

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

Решение будет негибким и не расширяемым, а значит оно не будет развиваться.

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

[ruslandh]

А нельзя хранение выделить в отдельный модуль с возможностью его замены?

[ruslandh]

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

[sb]

А нельзя хранение выделить в отдельный модуль с возможностью его замены?

База это отдельный (сам по себе) компонент (в виде файлов определенной структуры) и content-provider только морда, берущая данные из этой базы. А content-server и есть отдельный модуль, который обработкой, бэкапом и добавлением информации в базу занимается. Просто в контексте основной функции всей библиотеки данных (возможность просмотра информации, поиск по информации и сортировка) выгодно держать базы частью структуры свободно распространяемой cms при этом бэкап осуществляется простым копированием структуры каталогов (так же и миграция). Если вам надо данные, ну так они есть, просто путь не в отдельном каталоге, как многие привыкли видеть, а внутри структуры cms.

[ruslandh]

Ну  сделать так, чтобы протокол не был завязан на конкретную реализацию. Пусть sb делает как ему удобние, а если кто-то захочет базу привязать - ну и добавьте базу. Главное, чтобы структуры обмена были одинаковыми.

[neobht]

Sb, у меня сложилось впечатление, что вы sqlite и mysql спутали.
Хранить и бекапить sqlite базу проще - это всего один файлик.

[sb]

Главное, чтобы структуры обмена были одинаковыми.

В этом основная незадача и состоит. Ввиду того, что надо определить круг базового (поддерживаемого в виде категорий оборудования для того, чтобы гарантировать уникальность набора - бишь можно было бы определить, что в пробе есть оборудование, которого нет в базе в любой из категорий, которые мы опредедлили - сеть/звук/мосты/процессор и т.п.) оборудования, по которому высчитывать хэш (либо использовать уже имеющиеся программы сбора данных об оборудовании и завязываться на их уникальные идентификаторы), а у меня опыта в этом маловато прямо скажем, то все выливается в то, что процесс будет идти весьма не быстро. Если завязываться на идентификаторы имеющихся утилит (типа hwinfo), то процесс несколько ускорится, но только несколько, т.к. остается незадача sender-recipient, которую я на баше решать замудохаюсь (т.к. лично мое мнение, что тут нужен си/perl). Аналог простого веб-сервера, у которого ограничен функционал (фактически, основная функция его - прием данных и сверка данных с имеющимися в хранилище и выдача ответа в сторону клиента, в случае успешной проверки всех запросов - добавление данных в хранилище). Все. Ну и sender аналогично, только он готовит и посылает данные. Именно на него получается завязанным сейчас протокол обмена и выделение минимально необходимой информации для вычисления хэшей (либо использования уже готовых) и передачи их серверу.

[sb]

Sb, у меня сложилось впечатление, что вы sqlite и mysql спутали.
Хранить и бекапить sqlite базу проще - это всего один файлик.

Я вполне мог что-то спутать, признаю. Но фишка в том, что файлов, скорее всего, будет несколько (предполагаю по количеству категорий оборудования, здесь появляется возможность физически разделить базы по разным машинам, если, например, потребуется базу периферии расположить на другом хосте с другим публичным адресом в Сети). Почему так ? Да потому, что данных для периферии будет меньше, возможно там не будет каких-то полей и т.п. К тому же в теме вк предложение было по принтерам и сканерам. Про это тоже забывать не стоит, хотя сейчас не стоит гнаться за тем, чтобы охватить сразу все. Просто сканеры/принтеры и другую периферию добавлять будет проще. Да, это потребует внесения изменений в несколько компонент сразу, но эти изменения не будут большими и трудно обозримыми. И всегда сохраняется возможность переписать что-то в другом варианте, если это требуется или просто можно один из модулей заменить на другой, который отвечает вновь появившимся запросам и обстоятельствам.