Open Source - контест лог под Линукс

[RX1AL]

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

Mихаил Я все же думал про psp и моно эта такая тонкая шутка...
а сервер просто необходим и будет.

Роман, чтобы настроить Mono и P2P под ним - поседеть можно. Не все так просто. Спортировали пока далеко не все ещё. Под виндами, да, бежит, но основное требование - наличие PNRP+SYNC, а их в Mono нет, там по-другому изгаляться надо. Да и от ядра Линукса зависит сильно, не везде встает. Уже минус и ограничения. Если есть что-то, действительно хорошо работающего под Линукс, типа торрентов (где вся раздача на базе P2P), то можно сделать себе заметку на будущее. Но там же чанки, а они нам не нужны, т.е. опять надо будет много чего менять.

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

Если ран в это время будет лепить одно ЩСО за другим, мультовому месту при каждом переспросе придется отдавать каждый раз новый номер. Нефиг заморачиваться, надо сделать как в N1MM - там просто забили на пропуски и непоследовательность в номерах, за это не наказывают.

Асхат, молодец! Вот это я упустил из вида... Дeйствительно, если ран только и лепит номера, то тут... грабли. Причем реальные. Но решение в N1MM нам поможет, если не найдем лучшего...

[RN9RQ]

Михаил про тикль вместо перла то что думаете?

[US6IQ]

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

P.S.
В общем задача которую тут обсуждают весьма не проста и включает в себя достаточно много направлений. Обычно такого рода задачи решаются по принципу "один начинает - остальные подхватывают", иначе не выйдет. Кто-то должен взять на себя работу и ответственность первого Project Manager-a. Пускай потом все переделают, но нужен материал...

[RX1AL]

RN9RQ:
Да думаю... пока... Не мне же одному решать? Хотя, если писать, то TCL/TK ничем не плох. Кой чего там конечно не хватает, но думаю обойдемся. А интерфейс только на Qt. (с) "Адназначно!" - В. Жириновский

ПС У меня парсер уже готовый на перле зависает в этом случае...

Обычно такого рода задачи решаются по принципу "один начинает - остальные подхватывают", иначе не выйдет. Кто-то должен взять на себя работу и ответственность первого Project Manager-a. Пускай потом все переделают, но нужен материал...

Сергей, уже писали, что пора к главному перейти. Я абсолютно согласен. Все остальное пока мелочи. Заострятся на мелочах - не решим основного.
Вот-вот, надо выбрать project manager (чур не меня, у меня своих проектов навалом - не вылезаю, да и не мое это - писать согласен). Предлагаю, если не будет возражений RA6XTD, RX9TX или Kolotusha. Есть другие, обсудим. Для того, чтобы руководить, особых знаний в программировании не надо - нужно главное - видение и понимание цели и задач.

[RN9RQ]

6ну если тикль и тк то и интерфейс просто просится на них. Вы последнеи версии видели? оно темы поддержвает ив ОС встраивается номрально )
а парсер перенесется, галвнео идея, ен думаю, что вы там сильно круто завернули в парсере.

[US6IQ]

Попробовал тут изложить чего мне видится - проще начать писать

Можно рассмотреть архитектуру server -> (sub server -> client). Где sub server будет почти идентичен серверу, при отсутствии соединения ну и т.д.

Очень захватывает contest engine, с помощью описания кантеста (xml например) можно построить функционал всей системы в целом, вот с него надо начинать, все остальное придет в процессе.

[RN9RQ]

а зачем субсервер, если от сети отпал то работать нельзя

Добавлено через 1 час 5 минут
http://sk1.sourceforge.net/screenshots/sk1_cmyk.png
http://wiki.tcl.tk/13636
вид нативный какое окружение под то и встраивается

[VE3EUT]

Артур, именно! Наконец-то я увидел единомышленника в полном смысле слова. Нам действительно нужен vision statement - без него никуда.

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

Только не в направлении - есть позывной, вводим его в поле ввода, жмём клавишу enter и получаем какой-то результат и так далее. Не в этом ключе, так как это описывает лишь логику взаимодействия, т.е. MVC (Model-View-Controller) или новый MVVM паттерны. Нам пока сразу они не нужны. Документ vision statement описывает область применения (предметную область, если другими словами) - вот это нам и надо заложить в наш контест лог.

Тогда вот что бы я внес в vision

Mission

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

Подробнее

1. Простая инсталляция и конфигурация. Возможно загрузочный диск с линуксом и логгером и другими радиолюбительскими программами, заточенный именно для использования в тесте.
2. Это логгер только для соревнований и ни для чего больше, т.е. никаких репортов по DXCC, WAZ, печати наклеек и т.д. Только то, что нужно для контеста.
3. Максимально удобная и гибкая кастомизация под новый тип контеста, большое число уже готовых конфигураций под широко известные тесты
4. Поддержка общепринятых форматов для экспорта таких как например Cabrillo 1 и 2, открытый интерфейс для добавления экспортеров в новые форматы.
5. Поддержка многопользовательского режима.
6. Автодобавление, автопоиск,работа с master.dat.
6. Широкая поддержка оборудования, в том числе SO2R и работы с поворотками и коммутатором антенн.
7. Удобная работа с кластером. Удобная именно в условиях удаленной позиции без хорошего интернета. Например, возможность не только работать по телнету и TNC, но возможность работы и с ТВ-тюнером с поддержкой телетекста(а вдруг инет отвалился а кластер нужен)
8. Пост-процессинг, удобный режим проверки логов после соревнования и корректировка с сохранением версий изменений в том числе с использованием он-лайн баз позывных.

Ну и пока хватит наверное, это основное.

[R8TX]

Очень захватывает contest engine, с помощью описания кантеста (xml например) можно построить функционал всей системы в целом, вот с него надо начинать, все остальное придет в процессе.

Точно-точно, начните уже кто-нибудь

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

[VE3EUT]

Да, интеграция с google maps/google earth и Xearth. Показывать позывные, локейшны тех кто в кластере, страны, по которым отбомбились и т.д.

[UA9CIR]

Раздача номеров. Сейчас пока нет смысла усложнять обсуждение мелкими
деталями, достаточно определиться с принципом построения сетки (топология).
То есть рассмотреть плюсы и минусы вариантов сервер-клиенты ("звезда")
и клиент-клиент ("кольцо"). Житейская логика подсказывает, что один
начальник лучше, чем несколько, поэтому для выбора в пользу кольца
нужно назвать либо минусы звезды, либо плюсы кольца. Либо плюсы
какого-то третьего варианта.

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

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

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

73 Mike UA9CIR

[UD2F]

...

Подробнее
....
4. Поддержка общепринятых форматов для экспорта таких как например Cabrillo 1 и 2, открытый интерфейс для добавления экспортеров в новые форматы.
....

Сразу предусмотреть экспорт в EDI формат (REG1TEST для УКВ тестов).

Импорт из ADIF или cbr тоже был бы не лишним (как в N1MM), иногда очень надо !!!

Ну и поддерживаю, простота инсталляции аДназначна )

Все в одном, минимум подключаемых модулей (т.е. CW, кластер. банд мапы и т.п. изначально все "внутри").

[R8TX]

Все в одном, минимум подключаемых модулей (т.е. CW, кластер. банд мапы и т.п. изначально все "внутри").

CW и CAT в линуксе уже реализованы в виде демонов, тут вообще проблем быть не должно.

Добавлено через 4 минуты

Ну и поддерживаю, простота инсталляции аДназначна )

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

[RN9RQ]

Ну взгляд со своей колокольни
1. Только клиент-серверная архитектура, причем все что можно выносим на сторону сервера, в разумных пределах конечно.
Как то подсчет очков и прочее, на клиенте оставляем, и то для разгрузки сети, проверку на дубли master.dta вывод множителя, кластер,чат между клиентами, работу с железом (CAT поворотки и прочее).
2. Отсутствие БД, поскольку большая часть нагрузки ложится на сервер, то с задачей диспетчеризации обращений к файлу выполняться будет нормально.
Нормальный человеческий формат файла.Парсинг готов взять на себя если кто-то боится
3. Нормальная человеческая конфигурация, XML это не для нормальных людей. Парсинг человеческого конфига готов взять на себя
4. Начать построение архитектуры с максимально сложного варианта работы в сети много рановых и много мест на подхвате. Более простые варианты по нисходящей много проще реализовать.
А начинать не зная как это все будет выглядеть не надо, лишняя работа никому не нужна

[VE3EUT]

Только клиент-серверная архитектура, причем все что можно выносим на сторону сервера, в разумных пределах конечно.
Как то подсчет очков и прочее, на клиенте оставляем, и то для разгрузки сети, проверку на дубли master.dta вывод множителя, кластер,чат между клиентами, работу с железом (CAT поворотки и прочее).

В принципе, если поддерживать режим малти-малти, то клиент-сервер без вариантов. Причем, если пойти до конца и принять во внимание обеспечение простоты инсталляции и делать максимально тонкого клиента, то прихожу к выводу что самым разумным было бы в таком случае ajax/web приложение. Деплоить ничего на клиентов не нужно, вся обработка на сервере. Одинаково легко работают хоть 10 операторов.

Добавлено через 13 минут

CW и CAT в линуксе уже реализованы в виде демонов, тут вообще проблем быть не должно.

Да, причем, если к hamlib у меня нареканий нет, то вот с cwdaemon не все так хорошо. А вернее даже плохо. Управление портом производится полностью процессом, находящимся в пространтве пользователя, а значит о ни о какой более или менее реалтаймовой обработке не может идти и речи и любой своп процесс может портить передаваемый сигнал особенно на высоких скоростях. Что и происходит собственно, хоть и не часто. Это не проблема Линукса, в винде то же самое.
Но в Линуксе это решить проще, нужено написать соответствующий драйвер, который бы работал с cwdaemon но при работе через драйвер, все формирование посылок и отсчет временных интервалов бы реализовывались в пространстве ядра и соответственно сигнал бы был 100% качественным, как в TRLOG