Написание софта

[Verlan]

с точки зрения программиста:

Главное - это мощная и гибкая система поддержки плагинов (как в winamp`e) если этого добиться , то программа со временем обрастет всеми выше перечисленными функциями и ещё пепельницы вытрихать будет ...

P.S.
На мой взгляд это основная задача , иначе проект обречен на провал ...

[nmancer]

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

с точки зрения программиста:

Главное - это мощная и гибкая система поддержки плагинов (как в winamp`e) если этого добиться , то программа со временем обрастет всеми выше перечисленными функциями и ещё пепельницы вытрихать будет ...

P.S.
На мой взгляд это основная задача , иначе проект обречен на провал ...

на счет плагинов - согласен на все 100%.. но чтобы реализовать оное надо придумать какой то API для общения между оной программой и самим плагинами... создание _универсального_ API для общения между плагинами и ПО будет далеко не простой задачей..

по функционалу:
1) эмулятор денди/сега/etc

[_GLK_]

Как програмисит, делавший попытку в эту сторону, замечу, что плагинная система это удобно, но с точки зрения юзера.
Цельная программа всегда весит меньше и ест меньше ресурсов, не имеет лишнего гемора с межплагинной связь. плагинный Апи будет очень навороченный, если у меня к примеру есть ф-ция зависимости освещенности экрана от света в салоне, То основная программа, должна иметь эту ф-цию (и все плагины для совместимости даже,если она ему не нужна! ), а сколько таких будет "не стандартных" ? Здесь получится избыток лишних ф-ций. если я при цело-EXEшном варианте просто передаю значение через переменную. Объяснить сложновато, кто попробует, тот сразу увидит это дремучий лес.
Я считаю это не маловажной причиной для отказа от плагинов.
Хотя, у самого руки чешутся до плагинов

[Mox_2000]

Привет All

Вот решился влиться в ваши ряды.
Выскажу свое мнение по этому вопросу. Ну а в скорости и свою работу(автомобильный шел под Windows XP).

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

Результаты из собственного опыта
Все системы, поддерживающие плагины можно разделить на те что поддерживают красивый интерфейс и те которые расширяют функциональность приложения.
Т.е всегда нужно найти компромисс между красотой и функциональностью.
Я всегда выбираю функциональность + использование возможностей заложенных в OC

[Stan]

Есть еще одно предложение. Я по долгу службы изучаю архитекутру систем NGOSS (Next Generation Operational Support System) для операторов связи. Задачи сходны - создание единой системы, позволяющей комплексное управление услугами связи, реализованными на базе разного оборудования различных производителей.

Смысл архитектуры следующий. Создается, так называемая Enterprise Bus, некая шина, на которую насаживаются приложения (системы управления, билинги, CRM, ERP и прочая фигня). Естественно, возникает вопрос, как обеспечить совместимость этих систем через шину друг с другом. Для этого используются SID - формализованные блоки данных, описывающих услугу, элемент оборудования, абонента, что угодно, но в едином формате. Таким образом, достаточно создать шину, разработать SID и можно интегрировать системы.


Как переложить это на карпутеры?
1. Предположим создаем шину, общающуюся с внешними устройствами, для которых опредяляем единый формат данных.
Например - блок данных GPS, блок данных громкости и эквалайзера, блок данных управления радио, блок данных чего-нибудь еще.
2. Пишем приложения, какие угодно. Надо чтобы просмотрщик картинок запрашивал данные о скорости движения? Из приложения вызываем функцию GetData(arrGPS, vbGPS). Надо из телевизора звучащую в данный момент времени мелодию? GetData(arrMedia, vbMedia). Надо установить новую громкость для всех приложений? SetData(arrVolume, vbVolume).
3. Откуда возьмутся данные о GPS? их получит шина по NMEA. Но! Получит один раз, не надо никаких виртуальных портов, еще чего-то. Получила, и отдала любому приложению.
4. Очень удобно делать скины и расположение элементов. Например, определяем метку: LabelSpeed=120,100,140,110,GPS.Speed,Font,FontSize ,Color. А приложение уже само вытащит нужное данное.

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

Проблемы с интеграцией с радиатором? А зачем? Пишем небольшой драйвер, генерящий универсальный блок управления радио, который передается в шину.

Хотите писать приложение на С? А я на VB? Да ради бога. Не важно какие инструментальные средства, главное у всех унифицированные блоки данных.

Главное - системно проработать блоки данных и архитекутру шины.

Может попробуем начать? Функционал CarPC мы уже определяли. Теперь под него надо определить блоки данных

[Mox_2000]

Привет Stan

То что вы описали очень похоже на описание принципа функционирования сети CAN(Controller Area Network ). Т.е есть "сырые" данные а поверх них реализованы высокоуровневые протоколы передачи данных(преимущество - 5 уровневая модель ISO)

Для реализации такого канала потребуется реализация в простом случаи системной службы(или взять уже готовое решение от Microsoft), а в нормальном случае реализация специального сервера осуществляющего поддержку GUI, управление программами(данными) и расширения функциональности. [Вторым вариантом я сейчас и занимаюсь]

В конечном итоге мы получим набор взаимодействующих программ
+ свой специализированный графический UI.

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