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

**VE3EUT** · 04.04.2009, 09:19

Сообщение от RX1AL

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

Какой модуль ? Kernel module ? Или просто еще одну генерилку морзе кода, но только свою? Честно говоря не вижу смысла тратить на это время, cwdaemon нудо бедно делает свое дело, проблема с ним только на оч. больших скоростях да и то чтобы ее решить нужно ли писать драйвер или использовать электронный ключ с последовательным портом. Других вариантов не вижу если честно. Но cwdaemon это мне кажется не задача #1, это вполне изолированный кусок функжиональности который можно в любой момент выбросить из системы и заменить на что-то другое.

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

Сообщение от RX9TX

IARU, например, когда HQ обычно состоят из десятка разных станций в пределах одной IARU зоны.

И что ? Кому-то захочется порулить радио на удаленной позиции ? Все равно не понимаю, как эту возможность можно использовать.
Поетому вопрос остается открытым, какой смысл в консольном клиенте ?

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

Сообщение от RU2FM

Вот еще один ПРЕКРАСНО обоснованный довод в отказе дальнейшего развития tlf...
(при всем моем уважением к n6tr)

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

А если серьезно, то на текстовый конфиг вполне легко наворачивается GUI конфигурилка. Этот подход часто используется в линуксе и неплохо себя зарекомендовал. Поэтому может это просто отсутствующая фича в tlf которая со временем будет написана.

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

Сообщение от RX1AL

Конфирурацию клиента стоит хранить либо в базе (создается профиль), либо в XML. Редактор удобный для работы с конфигурационным файлом и пользовательскими секциями пишется быстро стандартными средствами. Плюсов полно, задача грамотно написать схему XSD, DTD - тут нас спасает могучая Altova или другой редактор XML схем, коих куча.

Мне кажется хранить в базе это слишком. Руками не поправишь случись что. XML или plain text думаю лучше всего подходит, причем наверное даже plain text скорее чем xml, потому как уж очень сложной иерархии в данном случае можно избежать и xml просто не нужен. Хотя это думаю непринципиально.

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

Сообщение от RX9TX

Кстати у xTLF нормальный графический интерфейс и конфигуратор. Может было бы проще просто форкнуть xTLF?

Там форкать особо нечего, в программе три с половиной строчки кода, практически минимум функциональности по сравнению с tlf.

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

Сообщение от RX9TX

Когда мы увидим хоть строчку кода?

У нас сейчас Definition Phase ;-) Еще рано, прежде чем начать что-то колбасить, необходимо определиться с набором фичей, архитектурой и многими вещами, нагородить кучу документов, вроде Project Charter, Vision Statement, Term of Reference, Statement of Work, Project backlog или Functional Requirement Specification да и много чего

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

**R8TX** · 04.04.2009, 10:18

Сообщение от EW1CK

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

Ух ты. Ну ждем

**RU3GA** · 04.04.2009, 11:24

Сообщение от RW3AKN

Господа не проще ли сначала написать консольный вариант, без Х-ов? потом к нему написать GUE, под gnome & kde,
Сначала нужно описать сруктуру хранения данных в БД

Вот золотые слова.
Давайте от них отталкиваться -- будет более-менее конструктивно.

Удачи!
RU3GA

**RX1AL** · 04.04.2009, 21:45

Вот сейчас сижу и дописываю два документа: Vision Statement и Functional Requirements. При этом имея постоянные проблемы с мобильным интернетом в горах. Надеюсь сегодня все закончить и выложить для дальнейшей правки. В документах ужтены практически все мысли тех, кто здесь высказывался. Также многое добавлено на основе функциональности существующих контест логов и понимания того, что нам ещё надо иметь.

ПС Документ будет в ворде. Скачиваем, читаем и правим. Можно выкладывать свои новые версии, можно по пунктам документа будет вести обсуждение в ветке.

**RW3AKN** · 05.04.2009, 01:12

Сообщение от RX1AL

ПС Документ будет в ворде. Скачиваем, читаем и правим. Можно выкладывать свои новые версии, можно по пунктам документа будет вести обсуждение в ветке.

Откуда скачиваем? Где ссылка? Если

Сообщение от RX1AL

Репозиторий будет открыт в понедельник на www.sourceforge.net, рабочее название проекта "Linux Contest Log".

**RX1AL** · 05.04.2009, 14:24

Сообщение от RW3AKN

Откуда скачиваем? Где ссылка? Если

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

**VE3EUT** · 06.04.2009, 02:50

Сообщение от RX1AL

Документ в ворде будет на форуме сначала... Часа через два выкладываю, надо еще кое-что дописать...

Инересно было бы посмотреть. Только может не стоит в doc формате, все-таки под Линукс собираемся писать а используем идеологически вредный формат ...

**R8TX** · 06.04.2009, 05:13

Сообщение от EW1CK

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

Точно, на него спецификации закрыты

**VE3EUT** · 06.04.2009, 17:57

Сообщение от RU3GA

Вот золотые слова.
Давайте от них отталкиваться -- будет более-менее конструктивно.

Не могу согласиться. На самом деле, проблему вы совершенно верно понимаете, а вернее риск того что проект может и не дойти до завершенного состояния а будет какой-то длительный срок находится в разобранном состоянии.
Т.е. проблему определили верно.
Но вот предлагаемое решение критики не выдерживает. Совершенно напрасно тратить силы на консольного клиента просто потому что он кажется более простым чтобы потом его выбросить через некоторое время.
Более оптимальным является разбиение процесса разработки на итереции. Не важно, это time based или scope based итерации, главное чтобы в конце каждой итерации на выходе появлялся вполне рабочий и юзаемый продукт.
Например, первая итерация - режим ввода/редактирования qso, поддержка телеграфного режима. Вторая итерация, экспорт в кабрилло, поддержка управления аппаратом через последовательный порт, занесение этих данных в qso. Ну и так далее.

**US6IQ** · 06.04.2009, 22:01

Сообщение от EW1CK

Совершенно напрасно тратить силы на консольного клиента просто потому что он кажется более простым чтобы потом его выбросить через некоторое время.

А вот тут вы не правы, хороший консольный клиент будет пользоваться не меньшей популярностью, чем Хавиндовый....

**RW3AKN** · 07.04.2009, 12:21

Сообщение от EW1CK

Но вот предлагаемое решение критики не выдерживает. Совершенно напрасно тратить силы на консольного клиента просто потому что он кажется более простым чтобы потом его выбросить через некоторое время.

Залог успешной программы что она должна быть модульная, консольный клиент, к нему GUI, коннекторы к разным БД, если не нужно все в файле хранить. Такая конструкция позволяет практически под любой linux дистрибутив поставить ПО. Обновлять опять же удобней. А если сделать монстра все в одном пакете, то возможны проблемы на разных дистрибутивах.
PS Мы сами создаем себе трудности что бы их потом преодолевать.

**VE3EUT** · 07.04.2009, 19:43

Сообщение от US7IQZ

А вот тут вы не правы, хороший консольный клиент будет пользоваться не меньшей популярностью, чем Хавиндовый....

А никто не говорит что будет хуже, просто консольный уже есть и очень даже неплохой, а именно tlf.

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

Сообщение от RW3AKN

Залог успешной программы что она должна быть модульная, консольный клиент, к нему GUI, коннекторы к разным БД, если не нужно все в файле хранить. Такая конструкция позволяет практически под любой linux дистрибутив поставить ПО. Обновлять опять же удобней. А если сделать монстра все в одном пакете, то возможны проблемы на разных дистрибутивах.
PS Мы сами создаем себе трудности что бы их потом преодолевать.

На счет модульности конечно согласен, тут спору нет. Вот на счет консольного клиента и GUI фронтенда на него есть большие сомнения. кка я понимаю вы предлагаете вариант вроде cvs/winCVS или нечто подобное.
Трудоемкость такого варианта будет существенно больше чем например разработка или только консольного клиента по типу tlf или GUI флиента вроде xtlf или xlog, я бы сказал практически в 2 раза. И ради чего собственно ? Чтобы предоставить еще один уровень абстракции на уровне командной строки. Вопрос, кому это надо и кто будет этим пользоваться ? Логировать связи во время теста из командной строки никто не будет, так как это неудобно и ненаглядно IMHO, а значит затея лишена практического смысла.