Уменьшение объема передаваемого кода программы

← →
vint45 (2004-06-26 14:41) [0]

Здраствуйте! Я хочу распространять свою программу через интернет.
Алгоритм программы занимает незначительный объем в отличие от интерфейсной части. Поэтому стоит их разделить, чтобы при обновлении только алгоритма, не приходилось заново обновлять и интерфейс. Я рассматриваю 3 варианта по отделению интерфейса и уменьшению объемов программы.

1 Вариант
Использование библиотеки KOL. Эта библиотека позволяет уменьшать размеры программы в 5-15 раз, правда сам я не пытался пока писать через нее программы, а только читал как с ней работать. Плюсом этой библиотеки является то, что она позволяет уменьшить размер компонентов за счет исключения вызова вирт. методов и
неиспользуемых в программе объектов. Но неизвестно поддерживает ли KOL работу с протоколом HTTPS и архивами. Некоторые интерфейсные компоненты, которые используются моей программой, могут не поддерживаться этой библиотекой (TCoolBar, TChart), или реализованы не полной мере (TTrackBar).

2 Вариант
Написание dll-плагинов. При написании dll-плагинов пишутся интерфейсные процедуры для вызова методов и свойств компонентов. Для каждого компонента создается свой плагин в целях уменьшения передачи данных при обновлении компонентов. Хотя плагины и не сжимают компоненты так как это делает KOL, но зато в них не хранится лишняя информация так как это происходит
при использовании package-модулей.

3 Вариант
Использование package-модулей. В этом варианте происходит отделение интерфейсной части от логики программы, но размер пакетов зашкаливает. В совокупе RTL и VCL занимают около 2 мегов (не считая вспомогательных пакетов, что может увеличить объем до 3-4 Мб), при этом скомпилированная без пакетов программа занимает
немногим более 600Кб. Т.е. в пакетах лежит много ненужной информации. Можно конечно править исходники и из них делать свои пакеты, но я читал что там много связей, которые довольно трудно разделить (отмечу также, что есть пакеты с компонентами, для которых у меня нет исходников).

Мастера! Помогите мне определиться с выбором варианта или поправьте меня, если я где-то не прав. Сам я склоняюсь к выбору второго варианта, мне кажется он наиболее компромисным. Спасибо.

← →
Sir John © (2004-06-26 16:06) [1]

Привет!
Если мое мнение учитывается, то могу посоветовать вот такой вариант.
1. Приложение должно быть откопилировано с включенным значком Build with Runtime Packages. Это уменьшит занимаемый объем в несколько раз. Для этого необходимо в Project -> Options выбрать закладочку Packages и установить соостветсвующий значок.

2. Узнать, какие библиотеки необходимы для распространения мы можем из меню Project -> Information for Project имя_проекта. Справой стороны в окошке Used packages Вы увидите список необходимых для нормальной работы программы библиотек.
Таким образом, пользователь вправе будет сам выбирать, что ему необходимо для загрузки.

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

← →
ЮрийК © (2004-06-26 16:08) [2]

dll-плагины отличаются от просто dll-ей?

← →
vint45 (2004-06-26 17:04) [3]

> ЮрийК © (26.06.04 16:08) [2]
Я думаю что в малой степени. Плагин имхо, это та же сама длл, только определенного формата, что позволяет подключать программе эти длл автоматически, без изменения своего кода.

>Sir John © (26.06.04 16:06) [1]
Использование Package меня все-таки не устраивает из-за размеров самих Packages.
А по поводу клиент-серверной технологии отмечу следующее. Программа моя состоит из серверной части (в ней происходят основные расчеты) функционирующей на стороне веб-сайта, и клиентской части, которую пользователи должны скачивать себе на машину. Основное назначение клиентской части, это отправление запросов в виде http-пакетов на серверную часть, получение ответа, и вывода его пользователю.
Так вот, мне важно уменьшить размеры именно клиентской части, чтобы легче было передать ее пользователям через инет.

← →
Sir John © (2004-06-26 17:16) [4]

тогда остается WinAPI. Ужасно маленькие экзешники получаются :)

← →
ЮрийК © (2004-06-26 17:25) [5]

Спроси и на КОЛ сайте про компоненты.

← →
KilkennyCat © (2004-06-26 18:31) [6]

> 2. Узнать, какие библиотеки необходимы для распространения
> мы можем из меню Project -> Information for Project имя_проекта.
> Справой стороны в окошке Used packages Вы увидите список
> необходимых для нормальной работы программы библиотек.
> Таким образом, пользователь вправе будет сам выбирать, что
> ему необходимо для загрузки.

Да, вот только для НОРМАЛЬНОЙ работы программы, их надо выбрать ВСЕ.

← →
Knight © (2004-06-26 23:29) [7]

Паковать исполняемый файл не пробовал...

← →
ПсихЪ_клон (2004-06-26 23:36) [8]

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

← →
K.o.Z (2004-06-26 23:47) [9]

Assembler :)

← →
vint45 (2004-06-28 10:45) [10]

>ПсихЪ_клон (26.06.04 23:36) [8]
Я задумывался над этим, даже пытался писать свой скриптовый язык. Но потом понял, что размер скомпилированной длл (в которой хранится только алгоритм, а интерфейс вынесен отдельно) мало отличается от размера скриптового файла. Замечу, что для скриптов, необходимо через инет первоначально скачать пользователям и сам интерпретатор, размер которого занимает немалый объем.

← →
Erik1 (2004-06-28 11:06) [11]

Из выше сказаного следует, что KOL для тебя подходит. KOL не подерживает работу с протоколом HTTPS и архивами, также ее неподерживает VCL! Нечего все мешать в одну кучу. Для обшения по HTTPS нужен невизуальный компенент, непример Indy. Инитерфейс придется переписать в любом случае, так что ныйдеш замену TTrackBar и пр..
Что касается TChart так это отденьный компонент и немаленький. Выбросить алгоритм в Dll тоже можоно, одно другово неисключает.

> KilkennyCat © (26.06.04 18:31) [6]
> Да, вот только для НОРМАЛЬНОЙ работы программы, их надо
> выбрать ВСЕ.

А вот это не соответсвует истине. Можно ограничиться только СВОИМИ пакетами.

← →
vint45 (2004-06-28 12:17) [13]

> Erik1 (28.06.04 11:06) [11]

> KOL не подерживает работу с протоколом HTTPS и архивами,
> также ее неподерживает VCL! Нечего все мешать в одну кучу.

Я и не говорил, что HTTPS - это VCL. В статье о KOL, говорится, что она может работать с обычными невизуальными компонентами. Просто я имел ввиду, что есть ли HTTPS-компоненты и т.п. адаптированные под работу KOL.
Вот выдержка из текста статьи по работе с KOL:
>Использование наследников TComponent из VCL
>Начиная с версии MCK v0.71, возможно использовать невизуальные >компоненты, основанные на VCL, в визуальных проектах KOL+MCK. >Для них будет сгенерирован код, их конструирующий, и >разрушающий, присвоены события и те свойства, которые >отличаются от присваиваемых в конструкторе.
>Тем не менее, использование компонентов VCL в проектах, >основанных на KOL, не рекомендуется, так как в любом случае >они> потянут за собой очень большой объем неиспользуемого кода.
Indy-компоненты все наследодованы от класса TComponent.

И потом, основу моего пользовательского интерфейса составляет компонент TChart, а это VCL-й компонент. Отказаться от него проблематично, а использование его в KOL исключается. Есть ли ему замена?

И еще повторюсь, я не пытаюсь сделать программу, которая занимала бы несколько килобайт. Мне не подходит использование чистого API и ассемблера, как некоторые советуют (моих познаний в этой области не хватает :) ). Основной момент, это разовая прокачка через интернет интерфейсной части программы, с возможностью повторного использования ее в дальнейшем без изменений в случае изменения алгоритма программы (допустим появится дополнительное окно настройки параметров). KOL хорошая штука, но смогу ли я ей воспользоваться, пока не знаю.

Уменьшение объема передаваемого кода программы Найти похожие ветки