Jyahd

Just yet another hardware database или сокращённо jyahd - сервис по сбору и обработке, а также предоставлению информации об используемом оборудовании, системном программном обеспечении и используемых настройках для каждого конкретного случая (пробы оборудования).

В настоящее время автором сервиса и единственным его разработчиком является Сергей Котляров.

Формат запросов на получение данных

Поскольку получение данных основано на определенном формате запросов к сервису (фактически запрос есть uri, который надо запросить у сервиса), то у программы клиента есть возможность отправить запрос и получить на него ответ в виде документа html, который, впрочем, может быть и пустым с точки зрения наличия в нём запрошенного содержимого. В этом случае ответ на вопрос, почему содержимое пусто, надо смотреть по полученным заголовкам ответа сервиса, а именно: по значениям полей Link и Title.

Для режима работы с данными проб и комментариями предназначен формат запросов вида

архитектура_проба~комментарий

где "проба" и "комментарий" - числа, назначенные соответственно запрашиваемой пробе и пробе, к которой запрашивается комментарий, а архитектура соответствует одному из значений arch. В данном запросе номер получаемой пробы и номер пробы, для которой запрашивается комментарий, могут быть различными. Также имеется шаблон для получения содержимого всех проб и/или комментариев. Для этого следует вместо номера (числа) применить дефис (например, получить все пробы и все комментарии "-~-", получить все комментарии "~-" или все пробы "-"). Статистику по пробам и комментариям получить нетрудно, для этого нужно в запросе указать ноль вместо номера ("0" для проб, "~0" для комментариев, "0~0" для проб и комментариев).

Для режима работы с содержимым логов предназначен запрос вида

архитектура_проба.лог

где "лог" может отсутствовать и тогда результатом запроса

архитектура_проба.

будет список реально доступных для запроса лог файлов конкретной пробы.

Если часть запроса архитектура_ не указана, то по умолчанию подразумевается раздел x86.

Внимание! В настоящее время реализован только arch для значений i586, i686, x86_64, т.е., фактически, база состоит только из раздела для машин на базе архитектуры x86

Возможности развития системы

1. Несмотря на то, что формат выводимых данных на сегодняшний момент неизменен, это всего лишь кажущееся постоянство. На самом деле формат выводимых данных может быть изменён вплоть до неузнаваемости. Но он не меняется по той простой причине, что нет предложений и запросов на изменение этого формата к виду, который может быть востребован. То есть, формат обсуждается и предложения по нему принимаются: как по форматированию, так и по объёму (по детальности).

2. Система накопления информации об оборудовании не содержит разбиения на категории (как это сделано в других подобных системах). Чтобы это можно было сделать, нужна реальная перспектива востребованности использования данной системы. А пока нет никаких признаков этого - нет и категорий. Другими словами, поиск по выводимой информации и так вам покажет искомый vid или pid в привязке к номерам проб. Для чего нужно разбиение на категории ? Только лишь для того, чтобы быть похожими на очередную базу которых в Сети есть ? Или, быть может, для того, чтобы рисовать диаграммы, показывающие процентовку от всего числа проб, содержащих то или иное конкретное железо ? Нет чётких и понятных критериев, для чего нужно разбиение на категории (и, самое главное, какой категории пользователей системы она нужна).

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

4. Серверная часть имеет закрытый код (условно открытый - можно так сказать, разъяснения по части лицензирования были отправлены mike, как и одна из промежуточных версий исходников), но это связано с тем, что сама серверная часть написана на коленке, требует внимания к себе по части безопасности (с учетом того, что возможности системы по сбору проб не должны пострадать).

5. Разработка ведется старинными методами: код клиента доступен только в виде srpm (автор - чайник и не имеет желания и времени на создание чего-то вроде github аккаунта или нечто подобного), источник srpm - тема на форуме. Планируется доработать данную статью, чтобы из неё был понятен механизм ("протокол") взаимодействия клиента и сервера. Это позволит создать желающим свой клиент на языке программирования, который ближе потенциальному автору такого клиента, причём клиент можно сделать и графическим (я не планирую делать какой-либо графический инструмент, например, для загрузки и подготовки к последующей загрузке проб на сервис как, наверное, самый востребованный среди простых пользователей). Однако, в отсутствии решения по 3-му и 4-му пунктам система рискует остаться невостребованной.

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