Страница 9 из 19 ПерваяПервая ... 2345678910111213141516 ... ПоследняяПоследняя
Показано с 121 по 135 из 280
  1. #121
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    Выкладываю черновик "Функциональные Требования" для обсуждения. Многие пункты требуют обсуждения и добавления, но на то и черновик. Просьба не бить... Добавляйте в него, что считаете нужным. Обсуждаем здесь в ветке, что нам еще нужно и что забыто.
    Вложения Вложения

  2. #122
    Very High Power Аватар для VE3EUT
    Регистрация
    21.11.2002
    Адрес
    East Gwillimbury, Ontario, CANADA
    Возраст
    52
    Сообщений
    2,282
    Поблагодарили
    260
    Поблагодарил
    228
    Пункт 4.5 выбросил бы сразу. Сеть должна обеспечиваться на уровне операционной системы.
    Смотрю дальше.

    Добавлено через 2 минуты
    Пункт 4.3 тоже непонятно, если мы делаем p2p с десктопными клиентами, зачем веб-интерфейс, а если делаем логгер на основе веб-интерфейса, то зачем p2p. IMHO что-то одно.

    Добавлено через 3 минуты
    Вообще нравится как написаны пункты 4.4 и 4.7

    Добавлено через 5 минут
    Пункты 4.1 и 4.2 разбил бы на множество мелких пунктов, как это сделано в 4.4 и 4.7, потом будет проще трейсить и имплементить эти требования.

    Добавлено через 7 минут
    Пункты 2 и 3 разбил бы на множество мелких пунктов, там каждый абзац просится в отдельный requirement. А потом бы об'еденил в одну главу Non Functional Requirements, в смысле Нефункциональные Требования.

    Добавлено через 11 минут
    Основной целью является создание контест лога на основе открытого кода (open source) для платформы Линукс, поскольку в настоящее время все имеющиеся контест логи имеют ограниченный выбор функциональных возможностей и в большинстве случаев не удовлетворяют потребности радиолюбителей, работающих в контестах.
    Вообще не нравится такая постановка вопроса. Упоминание о платформе Линукс несколько однобоко, зачем себя ограничивать. Если лог получится хороший, то можно собрать его под виндой(cygwin), mac os, freebsd и т.д. Т.е., я бы несколько расширил область применения и вместо Линукс написал бы "POSIX совместимая операционная система"

    Добавлено через 15 минут
    Контест лог обязан иметь такую архитектуру, которая позволит без особых проблем иметь возможность подключать различные модули, обеспечивающие дополнительную функциональность в зависимости от потребностей пользователя. При этом подключение дополнительных модулей должно производиться как на этапе установки контест лога, так и во время непосредственной работы с ним.
    Дополнительные модули функциональности должны быть построены на основе плагинов, демонов или отдельных программных модулей. При этом каждому пользователью должна быть предоставлена возможность выбирать те или иные модули, в зависимости от необходимости из полного списка дополнительных модулей. Каждый дополнительный модуль обязан быть хорошо документирован, чтобы обеспечить для пользователя минимальное время на изучение принципов работы с ним.
    Архитектура контест лога обязана быть такой, чтобы обеспечить наиболее удобную переносимость и расширяемость, без затрагивания основного ядра данного программного продукта.
    Вот это все очень здорово, еще бы грант от кого-нибудь получить. Очень похоже на Eclipse Rich Client Platform. Все это повторить ради контестового логгера IMHO очень небюджетно. Т.е. технически красиво, но дорого и долго.

    Добавлено через 18 минут
    На C/Qt или TCL/TK ничего похожего не видел, только Eclise RAP или Eclise RCP

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

    Добавлено через 22 минуты
    Архитектура контест лога должна поддерживать как базу данных, так и различные форматы файлов для хранения информации.
    Я бы слегка переформулировал. Хранение должно быть в одном формате, желательно human readable, но так же должна обеспечиваться поддержка импорта и экспорта данных в различные общепринятые форматы данных.
    Последний раз редактировалось VE3EUT; 08.04.2009 в 20:45. Причина: Добавлено сообщение
    Life's too short for QRP!
    73, Артур VE3EUT, EW1CK

  3. #123
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    EW1CK:
    Артур, спасибо за замечания. Естесственно не все гладко. Будем причёсывать. По пункту 4.5 - согласен, другое дело, как это грамотнее описать? Именно по функциональному требованию... Насчет "однобокости" Линукса... просто не додумал вопрос. Как-то в голове сидел только Линукс, про остальные платформы и не думалось. А ваша фраза как раз полностью отражает суть. Пункты 2 и 3 действительно надо разбить на подпункты - будет действительно легче потом. Артур, если есть какие-то мысли, то пишите прямо в тот же документ, только включите в ворде трекинг изменений, срзу будет видно, что было поправлено. И выкладывайте затем в топик новую версию. Тогда будет действительно коллективное творчество.

    Грант мы врядли получим... сначала надо начать, а потом углубить. И не похоже на Eclipse Rich Platform, а многие идеи просто оттуда позаимствованы. И они вполне реализуемы и в нашем случае. Только не на джаве, ради бога! Насчет долго, не знаю - смотря сколько народа писать будут и на чём. Под Qt 4.5 есть кстати, открытая библиотека для написания таких плагинов, как визуальных, так и нон-визуальных. В настоящее время изучаю возможности.

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

    ПС По поводу замечания про веб интерфейс. Была мысль на одном ядре иметь два типа клиента, не более. То есть стандартный графический клиент и клиент через браузер с почти одинаковой функциональностью. Ограничения будут, так как на веб не все реализуемо, что реализуемо для обычного клиента.

    Артур, в том виде, который называется Pluggable архитектура (как в Eclipse RCP) - Qt не поддерживает. Но писать плагины на Qt можно. Они поддерживаются уже с версии 3.0.5. Список в версии 4.5 намного расширен, то есть начинать с чего-то можно. Кроме того есть поддержка widgets, которые по сути могут быть плагинами. В дополнение ко всему, есть Qtopia Core, где есть специальные раширения для написания дополнительных плагинов. Кое-какой инструментарий имеется.
    Последний раз редактировалось RX1AL; 08.04.2009 в 21:43. Причина: Добавлено сообщение
    73! Михаил (OE6MAF) :: HB9/OE6MAF, DL/OE6MAF

  4. #124
    Low Power
    Регистрация
    09.06.2006
    Адрес
    Москва
    Возраст
    48
    Сообщений
    82
    Поблагодарили
    1
    Поблагодарил
    0
    Цитата Сообщение от RX1AL Посмотреть сообщение
    Добавляйте в него, что считаете нужным. Обсуждаем здесь в ветке, что нам еще нужно и что забыто.
    Цитата Сообщение от RX1AL Посмотреть сообщение
    4.2 Графический интерфейс должен поддерживать возможность работы приложения на нескольких мониторах.
    Этим занимается видеосистема ОС. К тому же уже описан этот функционал выше в документе "Графический интерфейс контест лога должен иметь возможность изменения размеров окон (resizing), их свободного позиционирования (floating) или фиксации (docking) на рабочем столе (desktop)."

    Цитата Сообщение от RX1AL Посмотреть сообщение
    4.5 Требования к поддержке сети
    Контест лог должен обеспечивать поддержку сети на уровне Ethernet, USB или RS-232 портов, а также их комбинации на одном компьютере или ноутбуке. При этом в качестве USB устройств могут быть использованы USB-Hub, USB-Ethernet адаптеры различных производителей.
    Поскольку логически и функционально сеть может быть организована несколькими способами, включая и P2P, то контест лог должен иметь возможность поддержки различных видов организации сетей, для обеспечения большей универсальности и унификации.
    Принципиально для организации сети могут применяться такие устройства, как Wi-Fi, Bluetooth, однако целесообразность их применения до включения в данную спецификацию нуждается в обсуждении.
    Я бы этот пункт изложил бы "контест лог должен взаимойдествовать с сетевой подсистемой операционной системы"

    Цитата Сообщение от RX1AL Посмотреть сообщение
    4.6 Требования к синхронизации контест лога
    Контест лог должен иметь возможность синхронизации лога "на лету" (on the fly), без участия центрального сервера.
    Здесь не понятно что значит без участия сервера? И с чем он синхронизируется?
    Последний раз редактировалось RW3AKN; 08.04.2009 в 23:56.
    73. RW3AKN :: ДА ПРИБУДЕТ С НАМИ ВОЛШЕБНАЯ СИЛА РАДИО!!!!!

  5. #125
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    Цитата Сообщение от RW3AKN Посмотреть сообщение
    Этим занимается видеосистема ОС. К тому же уже описан этот функционал выше в документе "Графический интерфейс контест лога должен иметь возможность изменения размеров окон (resizing), их свободного позиционирования (floating) или фиксации (docking) на рабочем столе (desktop)."

    Я бы этот пункт изложил бы "контест лог должен взаимойдествовать с сетевой подсистемой операционной системы"

    Здесь не понятно что значит без участия сервера? И с чем он синхронизируется?
    Про графический интерфейс: "Графический интерфейс контест лога должен иметь возможность изменения размеров окон..." - из этой фразы, не следует однозначно, что должна быть поддержка нескольких мониторов, так рабочий стол может быть на одном мониторе и все вышеописанные функции будут работать. Поэтому и был включен позднее ниже пункт про поддержку нескольких мониторов. То, что это обеспечивается на уровне ОС - это понятно. Если сможете более элегантно выразить ту же мысль в документе, будет хорошо... у меня не получилось в одной фразе.

    Фраза "должен взаимодействовать с сетевой подсистемой..." принимается. Так и есть.

    По поводу синхронизации "на лету" без участия центрального сервера. Имелось в виду, что если клиентское приложение имеет свою собственную независимую локальную базу или файловое хранилище, то клиент может иметь (или должен) синхронизироваться "на лету". Например, в случае, когда сервер стал недоступен по сети. То есть речь здесь идёт про поддержку режима оффлайн/онлайн для клиента. Если сервер доступен, то все данные сохраняются на нём, если соединение с ним пропало, то клиент начинает автоматически сохранять данные локально. Сервер появился - происходит процесс синхронизации данных. При наличии Р2Р, такую синхронизацию можно производить по всем рабочим местам без потери цикла работоспособности каждого места.

  6. #126
    Very High Power Аватар для R8TX
    Регистрация
    20.04.2005
    Адрес
    Оренбург, Россия
    Возраст
    58
    Сообщений
    3,390
    Поблагодарили
    614
    Поблагодарил
    119
    Я все-таки жду когда можно будет заказывать какие-то определенные фичи

  7. #127
    Very High Power Аватар для VE3EUT
    Регистрация
    21.11.2002
    Адрес
    East Gwillimbury, Ontario, CANADA
    Возраст
    52
    Сообщений
    2,282
    Поблагодарили
    260
    Поблагодарил
    228
    Вот немного поправил
    Вложения Вложения

  8. #128
    Very High Power Аватар для VE3EUT
    Регистрация
    21.11.2002
    Адрес
    East Gwillimbury, Ontario, CANADA
    Возраст
    52
    Сообщений
    2,282
    Поблагодарили
    260
    Поблагодарил
    228
    Цитата Сообщение от RX1AL Посмотреть сообщение
    И не похоже на Eclipse Rich Platform, а многие идеи просто оттуда позаимствованы. И они вполне реализуемы и в нашем случае. Только не на джаве, ради бога! Насчет долго, не знаю - смотря сколько народа писать будут и на чём. Под Qt 4.5 есть кстати, открытая библиотека для написания таких плагинов, как визуальных, так и нон-визуальных. В настоящее время изучаю возможности.
    Вот если честно вызывает вопросы идея полезности самих плагинов. Причина вот в чем, сама суть плагинов состоит в том чтобы дать какому-то числу сторонних разработчиков наворачивать какую-то функциональность к закрытому в общем-то ядру. Это не наш случай.
    Вторая причина по которой можно применять плаг-ины пусть даже и к открытому ядру - это большое количество часто конкурирующих между расширений. Это тоже случай когда приложение довольно широко распространено. Контестовые логгеры это не веб-браузеры и количество пользователей на порядок ниже, поэтому я сильно сомневаюсь что нам стоит заморачиваться с поддержкой рантаймовых плаг-инов на лету. Думаю вполне достаточно отинтерфейсить необходимые API на уровне исходного кода например или рантайм но как-то совсем по-простому как в apache modules API. Т.е. не выдумывать ничего грандиозного на тысячилетия вперед.

    Добавлено через 2 минуты
    Цитата Сообщение от RX1AL Посмотреть сообщение
    ПС По поводу замечания про веб интерфейс. Была мысль на одном ядре иметь два типа клиента, не более. То есть стандартный графический клиент и клиент через браузер с почти одинаковой функциональностью. Ограничения будут, так как на веб не все реализуемо, что реализуемо для обычного клиента
    Тут imho нужно с самого начала определиться или браузер или не браузер. А что касается убогости веб-интерфейса то не согласен. При использовании ajax все становится совсем даже неплохо.

    Добавлено через 4 минуты
    Цитата Сообщение от RX1AL Посмотреть сообщение
    Артур, в том виде, который называется Pluggable архитектура (как в Eclipse RCP) - Qt не поддерживает. Но писать плагины на Qt можно. Они поддерживаются уже с версии 3.0.5. Список в версии 4.5 намного расширен, то есть начинать с чего-то можно. Кроме того есть поддержка widgets, которые по сути могут быть плагинами. В дополнение ко всему, есть Qtopia Core, где есть специальные раширения для написания дополнительных плагинов. Кое-какой инструментарий имеется.
    Да я знаю, просто мне кажется что писать на C/Qt это будет гораздо более трудоемко. Если брать какой-то скриптовый язык типа Python/Perl/TCL/TK то будет побыстрее несколько и это тот вариант, на который нужно ориентироваться если выберем десктопное приложение.

    Добавлено через 8 минут
    Но кроме Eclipse RCP есть еще Eclipse RAP, который Rich Ajax Platform, я бы рассмотрел так же и его как вариант для веб-интерфейса, уверен что на нем девелопить будет быстрее чем на Perl/Qt например.

    Добавлено через 9 минут
    Цитата Сообщение от RX9TX Посмотреть сообщение
    Я все-таки жду когда можно будет заказывать какие-то определенные фичи
    Думаю уже можно
    Последний раз редактировалось VE3EUT; 09.04.2009 в 19:08. Причина: Добавлено сообщение
    Life's too short for QRP!
    73, Артур VE3EUT, EW1CK

  9. #129
    Very High Power Аватар для R8TX
    Регистрация
    20.04.2005
    Адрес
    Оренбург, Россия
    Возраст
    58
    Сообщений
    3,390
    Поблагодарили
    614
    Поблагодарил
    119
    Цитата Сообщение от EW1CK Посмотреть сообщение
    Цитата:
    Сообщение от RX9TX
    Я все-таки жду когда можно будет заказывать какие-то определенные фичи

    Думаю уже можно
    Я имел ввиду когда уже будет хоть как-то работающее приложение, можно будет говорить "хочу вот такую фичу" Думаю если будет несколько программеров, быстро воплощающих хотелки в код, то за год основную функциональность можно нарастить, дальше уже шлифовка и и изыски.

  10. #130
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    EW1CK:
    Артур, посмотрел ваши добавления в документе. Все здорово. Кое-что ещё добавлю, но в целом уже приемлемый документ.
    Теперь по выборе средств разработки и на чём писать... Вопрос далеко не праздный. Нужно устаканить это тоже. Ваше предложение использовать Eclipse RCP, RAP - поддерживаю. Не то, что я удивлён его появлением, нет, просто не убьют ли нас остальные программисты, за такое предложение. Всё-таки там джава в чистом виде. В любом дистрибутиве Линукса она уже есть по умолчанию, с этим никаких проблем. А вот если потом код будет переноситься на виндоуз платформу? Многие не очень-то предрасположены к наличию даже JRE на компьютере.

    С точки зрения удобства разработки на Eclipse RCP, считаю, что в данном случае мы имеем больше плюсов, так как наработок много, да и архитектура намного удобнее, чем Qt, TCL/TK. Графический интерфейс на Eclipse RCP выглядит просто замечательно. Опрос не хочется проводить, да и не зачем. Но все же определиться, прежде, чем начнём писать сам код - следует.

    Следующим этапом, правда, перед тем, как писать код, надо технические требования озвучить. И после них требуется создать UML по блокам, на логическом уровне и уровне функциональности. Так будет легче. Если будет база, а вроде её наличие не отрицается так сильно (если есть другие альтернативы, обсудим), то надо и её структуру описать. Артур вы можете здесь поучаствовать? С UML я готов сесть и начать ваять.

    ПС Предвижу появление вопроса от кого-нибудь - "а почему не на Mono платформе?" - и становится уже не по себе...

  11. #131
    Very High Power Аватар для R8TX
    Регистрация
    20.04.2005
    Адрес
    Оренбург, Россия
    Возраст
    58
    Сообщений
    3,390
    Поблагодарили
    614
    Поблагодарил
    119
    Цитата Сообщение от RX1AL Посмотреть сообщение
    А вот если потом код будет переноситься на виндоуз платформу?
    Нафиг не надо, двойная работа. Для венды уже есть N1MM, а с добавлением туда поддержки многотуровости вообще все вопросы с контест-логгером под венду снимутся. И консольный клиент тоже не нужен, опять двойная работа, есть TLF, проще попросить PA0R включить туда поддержку нужных тестов.

  12. #132
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    По поводу консольного клиента - Асхат, согласен... только потеря времени. Если делать то графичекий сразу. Артур предлагает делать для быстроты веб-клиент... Я бы не стал. Его и потом можно сделать, никто не мешает. Просто как-то со стандартным клиентом проще. Про виндоуз понял... согласен.

    EW1CK:
    Теперь нам надо структуру файловой системы (формат, поля) или структуру для таблиц базы данных определить. Я лично за базу данных, как-то привычнее. И можно уже что-то начинать писать. Структура должна быть ориентирована на объектно-оринетированный подход, с написанием классов и маппингом, т.е. то, что называется ORM, думается, Артур в курсе терминологии.
    Последний раз редактировалось RX1AL; 09.04.2009 в 22:25. Причина: Добавлено сообщение
    73! Михаил (OE6MAF) :: HB9/OE6MAF, DL/OE6MAF

  13. #133
    Very High Power
    Регистрация
    04.09.2008
    Адрес
    Одесса, Украина
    Возраст
    55
    Сообщений
    1,959
    Записей в дневнике
    2
    Поблагодарили
    113
    Поблагодарил
    161
    RX1AL
    Откликнитесь где нибудь по нашему вопросу

    Ребята а Вы что на Джаве будете писать лог?
    А чего QT не нравится
    Базу данных я раньше думал к mySQL привязать или Вы будете FireBird использовать?
    Я кстати на Gambas-е кое-что пробовал или это не пройдет
    Если MySQL то тогда можно легко использовать БД под веб-интерфейс

    RX9TX
    По поводу поддержки туров можно написать класс для этого соревнования и там указать что и как проверять, но надо наверно в БД поле добавить

    ППС в моей программе есть такое дело
    Последний раз редактировалось UR5FCM; 09.04.2009 в 22:51.
    Log4Win аппаратный журнал для повседневных связей и соревнований http://log4win.ucoz.net/

  14. #134
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    Цитата Сообщение от UR5FCM Посмотреть сообщение
    Ребята а Вы что на Джаве будете писать лог?
    А чего QT не нравится
    Если MySQL то тогда можно легко использовать БД под веб-интерфейс
    По поводу на чем писать, Игорь, еще до конца не определились... Просто Eclipse RCP перспективная платформа, да и проектов я на ней коммерческих делал много, знаю ее возможности. С Qt, TCL/TK - не сравнить. Насчет базы - уж точно не MySQL, слишком ограниченный набор функций. Там многого нет, что нам будет нужно.

    PS Игорь, через час-два отвечу тебе в личку, а код будет в твоем топике.

  15. #135
    Very High Power Аватар для VE3EUT
    Регистрация
    21.11.2002
    Адрес
    East Gwillimbury, Ontario, CANADA
    Возраст
    52
    Сообщений
    2,282
    Поблагодарили
    260
    Поблагодарил
    228
    Цитата Сообщение от RX9TX Посмотреть сообщение
    Я имел ввиду когда уже будет хоть как-то работающее приложение, можно будет говорить "хочу вот такую фичу"
    А, типа "ждем е-билдов" Вливайтесь, будет быстрее

    Добавлено через 6 минут
    Цитата Сообщение от RX1AL Посмотреть сообщение
    Вопрос далеко не праздный. Нужно устаканить это тоже. Ваше предложение использовать Eclipse RCP, RAP - поддерживаю. Не то, что я удивлён его появлением, нет, просто не убьют ли нас остальные программисты, за такое предложение. Всё-таки там джава в чистом виде. В любом дистрибутиве Линукса она уже есть по умолчанию, с этим никаких проблем. А вот если потом код будет переноситься на виндоуз платформу? Многие не очень-то предрасположены к наличию даже JRE на компьютере.
    Собственно RCP в данном случае это фреймворк, то, на чем он реализован это уже другой вопрос. По мне так совершенно не важно, java или что-то еще, важно то, какие он предоставляет возможности. Если например есть нечто похожее на C, Perl, Mono, на чем-то еще, давайте рассмотрим варианты. Но честно скажу, ничего похожего я лично не встречал. RCP же нам позволит сэкономить значительное количество времени и получить готовое приложение раньше. В этом его плюс.
    А если кому-то претит по религиозным соображениям держать на своем компе JRE, то пусть использует то что ему нравится(любой кошерный логгер на выбор). Предлагаю ориентироваться на здравомыслящих людей, думаю таких большинство.

    Добавлено через 7 минут
    Цитата Сообщение от RX9TX Посмотреть сообщение
    И консольный клиент тоже не нужен, опять двойная работа, есть TLF, проще попросить PA0R включить туда поддержку нужных тестов.
    Согласен.
    Правда догадываюсь, что скажет Рейн - вот молоток, вот гвозди, присылайте патч, я его с удовольствием закомичу.

    Добавлено через 8 минут
    Цитата Сообщение от RX1AL Посмотреть сообщение
    Артур вы можете здесь поучаствовать?
    Конечно поучаствую

    Добавлено через 27 минут
    Цитата Сообщение от RX1AL Посмотреть сообщение
    Теперь нам надо структуру файловой системы (формат, поля) или структуру для таблиц базы данных определить. Я лично за базу данных, как-то привычнее. И можно уже что-то начинать писать. Структура должна быть ориентирована на объектно-оринетированный подход, с написанием классов и маппингом, т.е. то, что называется ORM, думается, Артур в курсе терминологии.
    Михаил, вот тут как раз нужно сделать правильный выбор на мой взгляд.
    Если база, то скорее всего нет смысла держать по одному инстансу субд на каждой рабочей станции и мы таким образом скатываемся к двух-уровневой клиент-серверной архитектуре. Можно конечно для надежности держать второй инстанс на который будет идти бэкап, но сути это не меняет. продолжая мыслить в этом направлении, приходим к выводу что если базу держим в одном месте то логично выгрузить всю бизнес-логику на сервер приложения и поэтому плавно приходим к идее веб-клиента. Т.е. работа через веб-браузер с Ajax приложением с кучей браузерного джава-скрипта. Все будет красиво достаточно, но RCP тут не нужен, будет достаточно RAP или чего-то типа zkoss. Но это веб интерфейс сразу.

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

    Поэтому вижу 2 варианта - RCP клиент и хранение лога в текстовом формате на каждом компьютере с снхронизацией по известному p2p протоколу, например bittorrent(реализацию протокола берем конечно готовую, тот же Azureus например).

    RAP веб клиент с хранением лога в базе данных. В этом случае разработка будет еще несколько быстрее, плюс возможность использовать каких угодно клиентов, вплоть то Sony PSP, но сложнее деплоймент и при сбое лог править руками будет сложнее.
    Последний раз редактировалось VE3EUT; 10.04.2009 в 06:52. Причина: Добавлено сообщение
    Life's too short for QRP!
    73, Артур VE3EUT, EW1CK

Похожие темы

  1. Разработка open-source SDR
    от RELAYER в разделе SDR техника
    Ответов: 66
    Последнее сообщение: 19.03.2011, 09:12
  2. LZ open contest
    от 4L6QC в разделе Соревнования
    Ответов: 5
    Последнее сообщение: 17.01.2009, 23:57
  3. ОС Open Solaris
    от Кирилл в разделе Программное обеспечение
    Ответов: 8
    Последнее сообщение: 14.10.2008, 15:18
  4. Антенны Open Sleeve
    от UN7GCE в разделе Антенны КВ
    Ответов: 4
    Последнее сообщение: 19.10.2006, 08:02
  5. LZ Open
    от adani в разделе Соревнования
    Ответов: 4
    Последнее сообщение: 16.01.2006, 19:10

Социальные закладки

Социальные закладки

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
Похоже, что вы используете блокировщик рекламы :(
Форум QRZ.RU существует только за счет рекламы, поэтому мы были бы Вам благодарны если Вы внесете сайт в список исключений!
как отключить
×
Рейтинг@Mail.ru
eXTReMe Tracker


Похоже, что вы используете блокировщик рекламы :(
Форум QRZ.RU существует только за счет рекламы, поэтому мы были бы Вам благодарны если Вы внесете сайт в список исключений!
как отключить
×