Текущая версия от 06:44, 24 марта 2018

Внимание! Это статья о закрытом за невостребованностью сервисе.

Описание

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

Информация для пользователей систем ALT Linux/BaseALT

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

1. Загрузка данных об оборудовании на сервис (подготовить и отправить данные можно с помощью пока единственной программы клиента hcl-get), а также комментариев к пробе оборудования. Удаление данных об оборудовании вместе с комментарием (если добавлен) из базы сервиса (возможность доступна в hcl-get версии 0.3.99.40).

2. Получение информации об оборудовании и комментариях (в том числе и поиск по оборудованию и комментариям), а также получение содержимого логов.

Список логов и информации, которая собирается в пробу, можно посмотреть прямо в коде system-report, например, здесь.

Информация для потенциальных разработчиков, программистов

Протокол взаимодействия программы клиента с сервером

Формат запросов, используемый сервисом jyahd, представляет из себя часть запрашиваемого url. Ответ сервера будет в большинстве случаев представлять из себя документ html, который, впрочем, может быть и пустым с точки зрения наличия в нём именно запрашиваемого содержимого. В дополнение к html документу как полезной нагрузке сервер также возвращает ответ в виде значений полей Link (соответствует нумерации проб) и Title (соответствует номерам проб, к которым запрашивается комментарий), если запрос касался формата проб и комментариев, логов или статистики. Но сначала о формате запросов (часто именуемого uri).

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

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

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

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

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

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

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

Для поиска информации предназначен запрос вида

архитектура_где_ищем-что_ищем

где "что_ищем" — непосредственно содержимое поискового запроса, а "где_ищем" может быть одним из трёх указателей: q, qr и qc для данных проб совместно с данными комментариев, только данных проб и только данных комментариев соответственно.

Внимание! Для подобных запросов действует ограничение в 256 символов на суммарный url, включающий доменное имя. В большинстве случаев этого должно быть достаточно. Для более полновесных запросов предназначен вариант с запросом по методу POST.

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

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

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

Данный запрос осуществляется путём отправки запроса POST вида what=что_ищем&where=где_ищем. При этом где_ищем может быть одним из трёх: q, qr и qc для данных проб совместно с данными комментариев, только данных проб и только данных комментариев соответственно.

Формат ответа сервера на запросы по пробам, комментариям, логам, а также поиск

Как уже было сказано, сервер возвращает html документ, а также сигнализирует заголовками link (пробы) и title (комментарии) в зависимости от того, с каким форматом из вышеописанных пришёл запрос. Если формат запроса касается содержимого проб и комментариев, а также логов и статистики, то заголовки link и title соответственно могут принимать следующие значения:

f (found) — найдено
na (not available) — не добавлено для комментария
np (not processed) — найдено, но данные не обработаны (находятся в очереди на обработку)
nr (not requested) — не запрашивалось (для случая запроса, когда в запросе указывается только номер пробы или только номер пробы, для которой запрашивается комментарий)
nf (not found) — не найдено
wr (was removed) — было удалено
число — в случае запроса статистики покажет количество запрашиваемых элементов в базе

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

Примечания

@@ Строка 1: / Строка 1: @@
+{{Attention|Это статья о закрытом за невостребованностью сервисе.}}
 = Описание =
-'''Just yet another hardware database''' или сокращённо '''[http://hcl.arenet.ru jyahd]''' — сервис по сбору, обработке и предоставлению информации об используемом оборудовании, системном программном обеспечении и используемых настройках для каждого конкретного случая (пробы оборудования).
+'''Just yet another hardware database''' или сокращённо '''jyahd''' — сервис по сбору, обработке и предоставлению информации об используемом оборудовании, системном программном обеспечении и используемых настройках для каждого конкретного случая (пробы оборудования).
-В настоящее время автором сервиса и единственным его разработчиком является [[%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Sb|Сергей Котляров]]. Обо всех замеченных недочетах, ошибках, отсутствующих данных, предложениях по улучшению сервиса или по добавлению функционала сообщайте по указанным контактам, можно также сообщить [https://forum.altlinux.org/index.php?topic=36472.0 на форум], [https://vk.com/topic-667081_34397844 вконтакте раз] и [https://vk.com/topic-16711511_34413318 вконтакте два]. Отслеживаю везде, но не всегда это оперативно получается.
 = Информация для пользователей систем ALT Linux/BaseALT =
 == Возможности сервиса ==
-В данный момент для пользователей доступны следующие возможности:
-. Загрузка данных об оборудовании на сервис (подготовить и отправить данные можно с помощью пока единственной программы клиента [[Hcl-get_usage#.D0.9F.D0.B0.D0.BA.D0.B5.D1.82.D1.8B_rpm_.D0.B4.D0.BB.D1.8F_.D1.83.D1.81.D1.82.D0.B0.D0.BD.D0.BE.D0.B2.D0.BA.D0.B8_.D0.B8_srpm_.D1.81_.D0.B8.D1.81.D1.85.D0.BE.D0.B4.D0.BD.D1.8B.D0.BC_.D0.BA.D0.BE.D0.B4.D0.BE.D0.BC_.D0.B4.D0.BB.D1.8F_.D1.81.D0.B1.D0.BE.D1.80.D0.BA.D0.B8|hcl-get]]), а также комментариев к пробе оборудования
+. Загрузка данных об оборудовании на сервис (подготовить и отправить данные можно с помощью пока единственной программы клиента [[Hcl-get_usage|hcl-get]]), а также комментариев к пробе оборудования. Удаление данных об оборудовании вместе с комментарием (если добавлен) из базы сервиса (возможность доступна в {{pkg|hcl-get}} версии 0.3.99.40).
-. Получение информации об оборудовании и комментариях (в том числе и поиск по оборудованию и комментариям)
+. Получение информации об оборудовании и комментариях (в том числе и поиск по оборудованию и комментариям), а также получение содержимого логов.
+Список логов и информации, которая собирается в пробу, можно посмотреть прямо в коде system-report, например, [http://git.altlinux.org/people/sin/packages/?p=system-report.git;a=blob;f=system-report;h=6c2cd190acf0ef2a5eb531a96147ff414e7df009;hb=HEAD здесь].
 = Информация для потенциальных разработчиков, программистов =
 == Протокол взаимодействия программы клиента с сервером ==
-Формат запросов, используемый сервисом jyahd, представляет из себя часть запрашиваемого url (называемую uri). Ответ сервера будет в большинстве случаев представлять из себя документ html, который, впрочем, может быть и пустым с точки зрения наличия в нём именно запрашиваемого содержимого. В дополнение к html документу как полезной нагрузке сервер также возвращает ответ в виде значений полей Link (соответствует нумерации проб) и Title (соответствует номерам проб, к которым запрашивается комментарий), если запрос касался формата проб и комментариев, логов или статистики. Но сначала о формате запросов (uri).
+Формат запросов, используемый сервисом jyahd, представляет из себя часть запрашиваемого url. Ответ сервера будет в большинстве случаев представлять из себя документ html, который, впрочем, может быть и пустым с точки зрения наличия в нём именно запрашиваемого содержимого. В дополнение к html документу как полезной нагрузке сервер также возвращает ответ в виде значений полей Link (соответствует нумерации проб) и Title (соответствует номерам проб, к которым запрашивается комментарий), если запрос касался формата проб и комментариев, логов или статистики. Но сначала о формате запросов (часто именуемого uri).
-== Форматы запросов на получение данных проб и комментариев, а также логов ==
+== Форматы запросов на получение данных методом GET ==
-Для режима работы с данными проб и комментариями предназначен формат запросов типа GET и вида
+Для режима работы с данными проб и комментариями предназначен формат запросов вида
   архитектура_проба~комментарий
-где "проба" и "комментарий" — числа, назначенные соответственно запрашиваемой пробе и пробе, к которой запрашивается комментарий, а архитектура соответствует одному из значений {{cmd|arch}}. В данном запросе номер получаемой пробы и номер пробы, для которой запрашивается комментарий, могут быть различными. Статистику по пробам и комментариям получить нетрудно, для этого нужно в запросе указать ноль вместо номера ("0" для проб, "~0" для комментариев, "0~0" для проб и комментариев).
+где "проба" и "комментарий" — числа, назначенные соответственно запрашиваемой пробе и пробе, к которой запрашивается комментарий, а архитектура соответствует одному из значений {{cmd|arch}}. В данном запросе номер получаемой пробы и номер пробы, для которой запрашивается комментарий, могут быть различными. Статистику по пробам и комментариям получить нетрудно, для этого нужно в запросе указать ноль вместо номера ("0" для проб, "~0" для комментариев, "0~0" или "0~" для проб и комментариев).
 Для режима работы с содержимым логов предназначен запрос вида
@@ Строка 31: / Строка 32: @@
 где "лог" может отсутствовать и тогда результатом запроса '''архитектура_проба.''' будет список реально доступных для запроса лог файлов конкретной пробы.
+Для поиска информации предназначен запрос вида
+ архитектура_где_ищем-что_ищем
+где "что_ищем" — непосредственно содержимое поискового запроса, а "где_ищем" может быть одним из трёх указателей: '''q''', '''qr''' и '''qc''' для данных проб совместно с данными комментариев, только данных проб и только данных комментариев соответственно.
+{{Attention|Для подобных запросов действует ограничение в 256 символов на суммарный url, включающий доменное имя. В большинстве случаев этого должно быть достаточно. Для более полновесных запросов предназначен вариант с запросом по методу POST.}}
 Для любого из режимов если часть запроса '''архитектура_''' не указана, то по умолчанию подразумевается раздел x86.
+{{Attention|В настоящее время реализован только arch для значений i586, i686, x86_64, т.е., фактически, база состоит лишь из раздела для машин на базе архитектуры [https://ru.wikipedia.org/wiki/X86 x86].}}
+== Формат запросов на получение данных методом POST ==
-{{Attention|В настоящее время реализован только arch для значений i586, i686, x86_64, т.е., фактически, база состоит лишь из раздела для машин на базе архитектуры [https://ru.wikipedia.org/wiki/X86 x86]}}
+Данный запрос осуществляется путём отправки запроса POST вида '''what=что_ищем&where=где_ищем'''. При этом '''где_ищем''' может быть одним из трёх: '''q''', '''qr''' и '''qc''' для данных проб совместно с данными комментариев, только данных проб и только данных комментариев соответственно.
-== Формат ответа сервера на запросы по пробам, комментариям и логам ==
+== Формат ответа сервера на запросы по пробам, комментариям, логам, а также поиск ==
 Как уже было сказано, сервер возвращает html документ, а также сигнализирует заголовками link (пробы) и title (комментарии) в зависимости от того, с каким форматом из вышеописанных пришёл запрос. Если формат запроса касается содержимого проб и комментариев, а также логов и статистики, то заголовки link и title соответственно могут принимать следующие значения:
 * f (found) — найдено
+* na (not available) — не добавлено для комментария
 * np (not processed) — найдено, но данные не обработаны (находятся в очереди на обработку)
 * nr (not requested) — не запрашивалось (для случая запроса, когда в запросе указывается только номер пробы или только номер пробы, для которой запрашивается комментарий)
@@ Строка 45: / Строка 55: @@
 * число — в случае запроса статистики покажет количество запрашиваемых элементов в базе
-В настоящее время получить фильтрованный ответ для запросов содержимого проб, комментариев и логов (только информацию без оформления непосредственно веб страницы) можно, удалив из ответа всё, что не заключено в теги '''pre'''.
+Всё, что описано выше, уже позволяет написать простой клиент, который будет получать данные о результатах поиска, пробах, комментариях, лог файлах и показывать обработанный результат пользователю.
-Всё, что описано выше, уже позволяет написать простой клиент, который будет получать данные о пробах, комментариях, лог файлах и обработав результат, показывать пользователю.
-== Формат запросов на поиск данных ==
-Как вы уже наверное догадались, поиск осуществляется путем отправки запроса POST вида '''what=что_ищем&where=где_ищем'''. При этом '''где_ищем''' может быть одним из трёх: '''q''', '''qr''' и '''qc''' для базы проб совместно с базой комментариев, только базы проб и только базы комментариев соответственно. В настоящее время получить фильтрованный ответ (только информацию по результатам поиска без оформления непосредственно веб страницы) можно, удалив из ответа всё, что не заключено в теги '''pre'''.
-= Возможности развития системы =
-. Несмотря на то, что формат выводимых данных на сегодняшний момент практически не меняется, это кажущееся постоянство. На самом деле формат выводимых данных может быть изменён вплоть до неузнаваемости. Но он не меняется по той причине, что нет предложений от пользователей сервиса или просто заинтересованных на изменение этого формата. Формат обсуждается и предложения по нему принимаются: как по форматированию, так и по объёму (по детальности).
-. Система накопления информации об оборудовании не содержит разбиения на категории (как это сделано в других подобных системах). Чтобы это можно было сделать, нужна реальная перспектива востребованности использования данной системы (практически это означает написание отдельной системы с разбиением на категории, за что браться не вижу смысла ввиду малого интереса к разработке). Другими словами, поиск по выводимой информации и так покажет искомый vid или pid в привязке к номерам проб (или наименование железки по vid/pid). А разбиение на категории для чего ? Только для того, чтобы быть похожими на очередную базу из Сети ? Или для того, чтобы иметь диаграммы с процентовкой от всего числа проб того или иного вендора ? Нет чётких и понятных критериев, для чего нужно разбиение на категории (и, самое главное, какой категории пользователей системы подобное нужно).
-. Самое главное, чего не хватает для активного существования имеющейся системы, это живого отклика тех, кому подобная система нужна для '''реального использования''', а не просто затем, чтобы оно было.
-. Серверная часть имеет закрытый код (условно открытый можно сказать, разъяснения по части лицензирования были отправлены [[%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:MichaelShigorin|mike]], как и одна из промежуточных версий исходников), но это связано с тем, что сама серверная часть написана на коленке, требует внимания к себе по части безопасности (с учетом того, что возможности системы по сбору проб не должны пострадать).
-. Разработка ведется старинными методами: код клиента доступен только в виде srpm (автор — чайник и не имеет желания и времени на создание чего-то вроде github аккаунта или нечто подобного), источник srpm — [https://forum.altlinux.org/index.php?topic=36472.0 тема на форуме]. Планируется доработать данную статью, чтобы из неё был понятен механизм ("протокол") взаимодействия клиента и сервера (в том числе и в части подготовки и отправки данных, что пока не описано). Это позволит создать желающим свой клиент на языке программирования, который ближе потенциальному автору такого клиента, причём клиент можно сделать и графическим (я не планирую делать какой-либо графический инструмент, например, для загрузки и подготовки к последующей загрузке проб на сервис как, наверное, самый востребованный среди простых пользователей). Однако, в отсутствии решения по 3-му и 4-му пунктам система рискует остаться невостребованной.
-. Сама концепция сервиса позволяет расширять его функциональность в зависимости от реальных потребностей участников. Например, на базе сервиса можно относительно просто реализовать систему обмена сообщениями между участниками — теми, кто загружал на сервис пробы.
+= Примечания =
 [[Категория:HCL]]
 [[Категория:Hardware]]

Jyahd: различия между версиями