Идеальная структура оптимизатора : Программы OlegON

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

1. Оставить все, как есть и развивать текущую версию
+ Отлаженность онлайнового мониторинга и механизма в целом
+ Не трачу уйму времени только на переход и изменение структуры
+ Наличие готового ядра для добавления новых опций
+ Технически маловозможная способность взломать регистрацию
- Катастрофически неудобно писать, особенно изменения клиента. Куча условий должна сложиться, чтобы я просто мог это сделать. Не везде и не всегда могу писать, а тестирование вообще адски неудобное. Это очень сильно замедляет процесс разработки и, собственно, первопричина желания уйти от этого варианта.
- Архитектурная ошибка. Серверная часть на Java потребляет уйму памяти и проца для того, чтобы выдержать, например, 1000 клиентов сразу. Отсюда ограничения на количество подключений и неудобства для пользователей.
- Отсутствие графического интерфейса и невозможность его написания без дублирования разработки клиента - потеря пользователей.
- У многих серьезная проблема - невозможность пробросить порт либо через прокси, либо вообще нестандарт 7654
- Невозможность работы без сети (а сети у многих до сих пор проблемные в силу региона или кривых рук на местах)
2. Версия с графическим интерфейсом и ключом регистрации, мониторинг вынести в web.
+ Проще всего писать и можно будет это делать, где бы я ни находился
+ Проще пользоваться тем, кто не знаком с командной строкой
+ Значительное снижение нагрузки на сервер
- Все заново переписывать и писать очень много
- У меня далеко не везде есть графика (впрочем, думаю, можно это обойти)
- Программу сломают, тем более, что это Java. Отказаться от, например, даже 20000 в год жалко, а почему они должны платить за мой труд пользователи не понимают и добровольно платить никто не будет.
- Для кого-то проблема и в веб порт открыть или разграничить траффик

Добавлено через 19 минут 11 секунд
Если есть какие-то еще варианты - прошу озвучить. Но что однозначно должно присутствовать - связь программы по сети с головой у меня тут. Вот размышляю, каким образом это должно происходить. Дело в том, что основное, почему оптимизатор еще существует - возможность посмотреть тут, в центре, состояние базы, причем и историю. Теоретически можно двигаться в сторону второго варианта с мозгом у пользователя. Т.е. тюкнулся - нет связи, проверяем файловый ключ регистрации, если ничего нет - работаем в самом убогом варианте, например, только бекап проверяем, есть связь - проверяем статус HTTP-запросами и работаем в зависимости от полученного разрешения, если мой клиент - закидывать журнал по тому же HTTP...
Прошу помочь с идеями. Основное - уйти от текущей схемы, сохранить возможность мониторить без подключения локально, дать такую возможность пользователям и одновременно дать им стимул к регистрации оптимизатора.

Может несколько не в тему, т.к. оптимизатором давно не пользовался (нет сейчас баз на оракле), но:
Основная идея оптимизатора - это некий автолекарь, что ли. Т.е. нечто, что сделает всю работу за администратора. Соответственно - просто напрашивается следующая схема работы.
Некий клиент, cli или gui - непринципиально. Для снижения нагрузки на сервер - этот клиент должен нести в себе всю диагностику, плюс возможность по желанию админа отсылка логов на сервер. Еще раз повторюсь, возможность запуска оффлайн, но только диагностика, никакого решения проблем. Бесплатно. Т.е. на выходе некий лог из умных слов, в начале которого написано что-то типа "0 ошибок 10 предупреждений, база в порядке, спите спокойно". Или "10 ошибок 30 предупреждений, 6 из этих ошибок вы можете исправить автоматически за деньги, регистрация - ххх руб в месяц, остальные 4 ошибки - идите на олегон.ру и читайте умные статьи.".

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