Тип плагинов: Простой экспорт в папку

[vdemidov]

Я хочу сделать в ближайшее время простой экспорт в папку. Почему простой, а потому, что программа сама будет скармливать тайлы в том порядке в котором захочет, то есть склейку в растр скорее всего через такой экспорт сделать не получится, а вот копирование тайлов в какой-нибудь контейнер - запросто.
Интерфейс приблизительно такой:

Код: Выделить всё

  ISimpleTileProcessor = interface
    procedure ProcessTile(APos: Tpoint; Azoom: byte; ALonLatRect: TDoubleRect; ATileSize: Cardinal; ATileBuf: Pointer);
  end;
  IExportSimpleToFolder = interface
    function GetSupportedContentTypes: WideString;
    function StartExport(ASourceContentType: WideString; AFolderName: WideString): ISimpleTileProcessor;
  end;


Тоесть SAS.Планета сама будет перебирать тайлы по выделению, и скармливать плагину, порядок и наличие всех тайлов не гарантируется.
PS: Добавил работу с типом содержимого тайлов.
Функция GetSupportedContentTypes возвращает список поддерживаемых плагинов типов исходных данных приблизительно в таком виде:
"image/jpeg"; "image/png"; "image/gif"; "application/vnd.google-earth.kml+xml"
Если возвращается пустая строка, значит плагин ничего не поддерживает и в списке ни для одного из источников показываться не будет.
Функция StartExport получает тип данных экспортируемого пользователем источника.

[vmax]

O! Почти то что надо. Осталось устаканить интерфейс и смогу написать плагинчик ....

Начнем с того чего не хватает в этом интерфейсе
1. Метода для получение названия вида экспорта( что вы будете показывать в селекторе выбор типа экспорта? )
2. Метода FinishExport ( для того что-бы завершить процедуру экспорта - например закрыть файлы индексов и данных )

Теперь вопросы..к функции ProcessTile
ATileBuf: Pointer - Что в этом параметре? растр тайла? или бинарные данные - содержимое файла как оно есть на диске?
APos: Tpoint - Что в этом поинте? координаты тайла в текущем зуме? или номера N,M тайла?

Очень было бы желательно что бы вы выложили либо пустую рыбу интерфейса
либо базовую имплементацию простого экспорта. В качестве образчика.

[vmax]

Упустил еще одну вещь ... в этом методе не хватает еще одного параметра
function StartExport(AFolderName: WideString): ISimpleTileProcessor;
Если как я пологаю AFolderName это директория куда валить выхлоп упаковщика то хотелось бы еще иметь
один параметр - имя источника (поддиректории кэша ака SAT, MAP .... итд)

Попробую описать как сейчас работает мой паковщик (отдельное приложение)
который я хочу сделать плагином..
1. Юзер кажет пальцем на директорию кэша планеты.
2. Выбирает набор источников которые надо упаковать
3. Указывает директорию куда валить упакованное.
Упаковщик для каждого из выбранных источников
сливает все тайлики в файлы нарезанные по 1гигу именуя их по принципу
sat.d00, sat.d01 ....
и строит индексный файл sat.inx
Вот для этого то мне как раз и нужно знать имя источника (исходную поддиректорию кэша)

[vdemidov]

1. Метода для получение названия вида экспорта( что вы будете показывать в селекторе выбор типа экспорта? )

Ну я собирался для этого использовать методы PluginAPI. Там у каждого плагина есть Name и Description

2. Метода FinishExport ( для того что-бы завершить процедуру экспорта - например закрыть файлы индексов и данных )

Такой метод абсолютно бесполезен и вреден. Все закрытия файлов нужно делать в деструкторе объекта с интерфейсом ISimpleTileProcessor.

Теперь вопросы..к функции ProcessTileATileBuf: Pointer - Что в этом параметре? растр тайла? или бинарные данные - содержимое файла как оно есть на диске?

Содержимое файла в чистом виде.
Согласен нужно в StartExport как-то предавать тип данных. И крайне желательно получать от плагина список обрабатываемых типов. Нового изобретать ничего не будем, возьмем стандартный Content-Type http://en.wikipedia.org/wiki/Content-Type

APos: Tpoint - Что в этом поинте? координаты тайла в текущем зуме? или номера N,M тайла?

Да это номер столбца и строки тайла в зуме Azoom.

Очень было бы желательно что бы вы выложили либо пустую рыбу интерфейса

А что, по-вашему, выложено в первом посте. Конечно это первая версия, но сильных изменений не будет.

либо базовую имплементацию простого экспорта. В качестве образчика.

Пока не готово, но скорее всего будет какой-то примитивный экспорт в папку.

Если как я пологаю AFolderName это директория куда валить выхлоп упаковщика то хотелось бы еще иметьодин параметр - имя источника (поддиректории кэша ака SAT, MAP .... итд)

Имя источника это пока больной для меня вопрос. Что отдавать?
Название папки, которое есть сейчас? А вы знаете что там может быть полный путь? А что в перспективе это может быть имя файлового хранилища или строка подключения к базе данных, или скорее всего вообще ничего не быть так как автор плагина-хранилища решит хранить название базы в другом параметре?
Название текстовое, которое показывается пользователю? Так оно может легко меняться.
Сейчас уникальным идентификатором источника является GUID, но не уверен что он вам поможет.
Да и вообще простой экспорт подразумевает проход по одному источнику. Следовательно это будет одна результирующая папка, а уж ее имя пусть выбирает пользователеь. Так что ориентируйтесь, что если AFolderName содержит что-то типа: "C:\Temp\SatYa" создавать файлы SatYa.d00, SatYa.d01, ... и индексный файл SatYa.inx

[vmax]

Спасибо за быстрый отклик

1. Метода для получение названия вида экспорта( что вы будете показывать в селекторе выбор типа экспорта? )

Ну я собирался для этого использовать методы PluginAPI. Там у каждого плагина есть Name и Description

Извини, может глупость спрошу, Можно ткнуть пальцем где искать описание методов PluginAPI?
Я увы в Дельфях как слон в помидорах. Java, C, C#, C++, Perl, Fortran а до Дельфи как-то руки не доходили.
Лелею мыслю как бы плагин то реализовать на С/C++ что-бы не разбираться с Дельфями..
Ну да видно проще будет разобраться с Дельфи чем с граблями при мапировании типов данных
и вызывов из дельфей в сишные. К примеру в упор не смог пока понять что такое WideString
и как его мапировать в сишные типы данных. Так что придется для надежности на Дельфях
писать и тут бы сильно помог готовый образчик полной имплементации.

2. Метода FinishExport ( для того что-бы завершить процедуру экспорта - например закрыть файлы индексов и данных )

Такой метод абсолютно бесполезен и вреден. Все закрытия файлов нужно делать в деструкторе объекта с интерфейсом ISimpleTileProcessor.

Ну я бы не был столь категоричен. Классика программирования вполне допускает
переиспользование объектов. Хотя в данном конкретном случае действительно проще рожать новый
инстанс объекта на каждый экспорт а потом его прихлопывать.
Но поскольку из интерфейса не следует однозначного вывода о таком способе работы
потому и появилось желание явного завершения процесса.

Теперь вопросы..к функции ProcessTileATileBuf: Pointer - Что в этом параметре? растр тайла? или бинарные данные - содержимое файла как оно есть на диске?

Содержимое файла в чистом виде.
Согласен нужно в StartExport как-то предавать тип данных. И крайне желательно получать от плагина список обрабатываемых типов. Нового изобретать ничего не будем, возьмем стандартный Content-Type http://en.wikipedia.org/wiki/Content-Type

Новое придется изобретать даже в этом случае. Content-Type для tne файлов

Очень было бы желательно что бы вы выложили либо пустую рыбу интерфейса

А что, по-вашему, выложено в первом посте. Конечно это первая версия, но сильных изменений не будет.

В посте я вижу только декларацию интерфейсов. Для человека впервые осваивающего Дельфи
это таит массу подводных камней и недосказанностей. К примеру не видно где тут GUID и где Name и версия.
Их тут нет. Они в другом месте. Тогда явно не хватает информации о том как сделать законченный плагин.
Рыба в моем понимании это исходник плагина с неимплементироваными (пустыми) функциями.
В который нужно только дописать конкретную имплементацию.
Либо (по аналогии с явой) базовый абстрактный класс в котором необходимо только
имплементировать недостающие методы.

либо базовую имплементацию простого экспорта. В качестве образчика.

Пока не готово, но скорее всего будет какой-то примитивный экспорт в папку.

А вот за это отдельное спасибо. Просто сгораю от нетерпения

Если как я пологаю AFolderName это директория куда валить выхлоп упаковщика то хотелось бы еще иметь один параметр - имя источника (поддиректории кэша ака SAT, MAP .... итд)

Имя источника это пока больной для меня вопрос. Что отдавать?
Название папки, которое есть сейчас? А вы знаете что там может быть полный путь? А что в перспективе это может быть имя файлового хранилища или строка подключения к базе данных, или скорее всего вообще ничего не быть так как автор плагина-хранилища решит хранить название базы в другом параметре?
Название текстовое, которое показывается пользователю? Так оно может легко меняться.
Сейчас уникальным идентификатором источника является GUID, но не уверен что он вам поможет.

Ну не текстовое название конечно
Имхо ключевое слово здесь "источник" и его имя присутствует как в именах папок так и в именах
zmp файлов. ака SAT, MAP итп. Дефакто это имя (кодовое) уже есть.
Под источником я понимаю исходный источник данных - то откуда эти данные были взяты
а не то где они потом были сложены. Так давайте его и использовать. Чем плохо?
Источник SAT - типа спутниковые снимки от гугла так им и останется даже если придется
менять урлы, гуиды и хранить в разных типах кэшехранилищей.
Имхо ИМЯ источника такая-же характеристика тайла как зум и номера позиции.
GUID действительно мало поможет разве что держать еще где-то словарик мапирования
гуидов в имя источника. Но GUID может и поменяться при переходе на другой тип хранилища
а google как был гуглом так и останется

Да и вообще простой экспорт подразумевает проход по одному источнику. Следовательно это будет одна результирующая папка, а уж ее имя пусть выбирает пользователь. Так что ориентируйтесь, что если AFolderName содержит что-то типа: "C:\Temp\SatYa" создавать файлы SatYa.d00, SatYa.d01, ... и индексный файл SatYa.inx

[/quote]
Такой подход в моем конкретном случае не очень прокатывает.
Попробую пояснить на примере SASПланеты
Если в директории CACHE папочку SAT я поименую как sat_google планета же ее не найдет, потому
что где-то у вас прописано что папка должна называться SAT. Вот и у меня та-же история.
имена файлов прописаны в конфиге.
Т.е. имена файлов привязаны к источникам так же как у вас к источникам привязаны директории.
И полагаться на то что пользователь введет правильные имена очень не хочется. Лишняя головная боль.

Логика экспорта в моем случае подразумевает что экспорт будет всех источников в одну и ту-же
базовую папку (аналог папки CACHE в планете) и тогда имена файлов просто получается не из чего строить.

[vdemidov]

Извини, может глупость спрошу, Можно ткнуть пальцем где искать описание методов PluginAPI?

Не глупость и ткнуть пальцем пока некуда. Имеется в виду API, котороя я для SAS.Планеты сейчас придумываю и реализовываю. Поэтому доки пока нет.

Лелею мыслю как бы плагин то реализовать на С/C++ что-бы не разбираться с Дельфями..

Ну я сам думая о плагинах, всегда думал о возможности писать плагины на С++, но для этого нужно будет перевести все объявления базовых интерфейсов с Делфи на С. А я это сделать еще не готов. Ибо лень в случае изменений в них, править это еще и на С или ловить глюки, если забыл поправить.

Ну да видно проще будет разобраться с Дельфи чем с граблями при мапировании типов данных и вызывов из дельфей в сишные.

Пока именно так. Простые вещи проще написать на Делфи. На сишке будем писать, когда понадобиться использовать библиотеки с сишными интерфейсами. Например Беркли ДБ.

К примеру в упор не смог пока понять что такое WideStringи как его мапировать в сишные типы данных.

Это чистый COM-вский BSTR.

Ну я бы не был столь категоричен. Классика программирования вполне допускает переиспользование объектов. Хотя в данном конкретном случае действительно проще рожать новый инстанс объекта на каждый экспорт а потом его прихлопывать. Но поскольку из интерфейса не следует однозначного вывода о таком способе работы потому и появилось желание явного завершения процесса.

Именно что следует. StartExport порождает новый объект с другим интерфесом, который умеет только обрабатывать файлы. Что с ним делать потом если у него вызвать FinishExport?

Новое придется изобретать даже в этом случае. Content-Type для tne файлов

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

В посте я вижу только декларацию интерфейсов. Для человека впервые осваивающего Дельфиэто таит массу подводных камней и недосказанностей. К примеру не видно где тут GUID и где Name и версия.Их тут нет. Они в другом месте. Тогда явно не хватает информации о том как сделать законченный плагин.Рыба в моем понимании это исходник плагина с неимплементироваными (пустыми) функциями.В который нужно только дописать конкретную имплементацию. Либо (по аналогии с явой) базовый абстрактный класс в котором необходимо только имплементировать недостающие методы.

А это все к функции экспорта никакого отношения не имеет. Если реализовать те интерфейсы, что я привел в виде готовых классов, то сделать потом из них плагин составит 10 минут времени. Просто я еще не готов публиковать интерфейсы PluginAPI SAS.Планеты, а тем более Plugin SDK. Но со временем это все конечно будет.

А вот за это отдельное спасибо. Просто сгораю от нетерпения

Это хорошо, но просто время у меня весьма ограничено, поэтому и предложил в этих темах начать обсуждать и реализовывать отдельные плагины еще до публикации SDK.

Такой подход в моем конкретном случае не очень прокатывает.Попробую пояснить на примере SASПланетыЕсли в директории CACHE папочку SAT я поименую как sat_google планета же ее не найдет, потому что где-то у вас прописано что папка должна называться SAT. Вот и у меня та-же история. имена файлов прописаны в конфиге.

В Планете это может быть изменено пользователем прямо из пользовательского интерфейса. В том числе и на d:\ggg\sat_google или еще что-то. Название zmp, тоже может меняться. В общем, этот тип плагинов об источнике ничего знать не будет. Примите это как данность. А вообще я бы посоветовал поменять в своей программе структуру папок. На что то типа Cache\Sat\S01.dat, Cache\Sat\S02.dat,..., Cache\Sat\Index.inx, Cache\YaSat\S01.dat, Cache\YaSat\S02.dat,..., Cache\YaSat\Index.inx

[vmax]

Ну я сам думая о плагинах, всегда думал о возможности писать плагины на С++, но для этого нужно будет перевести все объявления базовых интерфейсов с Делфи на С. А я это сделать еще не готов.

Если вы держите в уме такую возможность то есть пожелание пересмотреть интерфесы на предмет использования
вместо специфичиских дельфевых типов базовых типов легко мапирующихся в типы практически в любого другого
языка. т.е. избегать использования составных структур вроде Tpoint; TDoubleRect заменив их на набор простых переменных базовых типов и таких специфичных типов как Cardinal;
Тогда интерфейсы будет гораздо проще портировать на другие языки.

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

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

В общем, этот тип плагинов об источнике ничего знать не будет. Примите это как данность.

Избыточность информации (имея ввиду происхождение тайла из конкретного источника) вряд-ли может повредить.
А вот ее недостаточность восполнить достаточно сложно.

Возьмем для примера базовый юзкейз простого переноса данных выделенной области.
Юзверь выбирает набор источников для экспорта и набор зумов для экспорта.
Указывает БАЗОВУЮ директорию для экспорта и жмет кнопочку экспорт.
(ну я тут ничего нового не придумал ведь)
Приплыли. Предложенным интерфейсом в отсутствии инфы о принадлежности тайла к источнику
(либо отсутствия параметра "источник" в методе StartExport) такой юзкейз нереализуем.
Значит придется придумывать другой интерфейс под такой юзкейз. А этот простой
так и останется видимо невостребованным поскольку экспорт по одному источнику
тут-же поднимет волну пожеланий сделать оптовый вариант.

А вообще я бы посоветовал поменять в своей программе структуру папок. На что то типа Cache\Sat\S01.dat, Cache\Sat\S02.dat,..., Cache\Sat\Index.inx, Cache\YaSat\S01.dat, Cache\YaSat\S02.dat,..., Cache\YaSat\Index.inx

Да я уже подумал про такой вариант. Но тогда появляется очень неприятная зависимость
завязки конфига моей программы на навигаторе на
имена папок которые придется пользователю вводить руками при экспорте из планеты.

Какой процент юзеров занимаются изменением имен директорий источников (1%?)
99% пользуют как есть и не заморачиваются. А тот 1% который это делает он уже как минимум
способен разобраться.
Проблема с теми самыми 99% пользователей которые НЕ СПОСОБНЫ ввести НУЖНЫЕ 10-20-30 имен директорий
БЕЗ ОШИБОК так как они прописаны в конфиге ( в полном соответствии с именами директорий в .zmp )

И в этом случае очень бы помогло именно некое логическое имя (идентификатор) источника
передаваемое при экспорте.

Подозреваю что же самое имя(идентификатор) источника потребуется и интерфейсу хранилища тайлов
Я вобщем то готов согласиться на GUID источника... (ну придется мне держать мапу GUID->базовое имя файла)
Единственно не хочется что-бы GUID этот менялся при каждом чихе (например подправили урлу гуглового спутника, GUID останется старым или тоже изменится? )

Что у вас является ключом(идентификатором) источника в селекторе выбора источника
при экспорте? GUID?

Почему я не люблю GUIDы это потому что они не юзер-фриендли. Углядеть глазами ошибку в GUID
практически невозможно. Понять к чему этот GUID относится тоже. Сам по себе GUID не дает никакого
даже намека о том что он идентифицирует. Всегда старался придерживаться концепции максимальной
понятности и прозрачности. В этом смысле URI гораздо более адекватное изобретение.

[vdemidov]

Если вы держите в уме такую возможность то есть пожелание пересмотреть интерфесы на предмет использования вместо специфичиских дельфевых типов базовых типов легко мапирующихся в типы практически в любого другогоязыка. т.е. избегать использования составных структур вроде Tpoint; TDoubleRect заменив их на набор простых переменных базовых типов и таких специфичных типов как Cardinal;Тогда интерфейсы будет гораздо проще портировать на другие языки.

Лучше я один раз опишу на С++ структуры TPoint и TDoubleRect, чем буду увеличивать количество параметров во всех функциях интерфейсов.\

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

Именно что философский. Я против любых излишеств. В этом типе плагинов будет передаваться только инфа о имеющихся тайлах.

Избыточность информации (имея ввиду происхождение тайла из конкретного источника) вряд-ли может повредить. А вот ее недостаточность восполнить достаточно сложно.

Повредить может и избыточность. В общем опять таки философский вопрос.

Возьмем для примера базовый юзкейз простого переноса данных выделенной области.Юзверь выбирает набор источников для экспорта и набор зумов для экспорта.

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

Приплыли. Предложенным интерфейсом в отсутствии инфы о принадлежности тайла к источнику (либо отсутствия параметра "источник" в методе StartExport) такой юзкейз нереализуем. Значит придется придумывать другой интерфейс под такой юзкейз. А этот простой так и останется видимо невостребованным поскольку экспорт по одному источнику тут-же поднимет волну пожеланий сделать оптовый вариант

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

Да я уже подумал про такой вариант. Но тогда появляется очень неприятная зависимостьзавязки конфига моей программы на навигаторе наимена папок которые придется пользователю вводить руками при экспорте из планеты.

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

Какой процент юзеров занимаются изменением имен директорий источников (1%?) 99% пользуют как есть и не заморачиваются. А тот 1% который это делает он уже как минимумспособен разобраться. Проблема с теми самыми 99% пользователей которые НЕ СПОСОБНЫ ввести НУЖНЫЕ 10-20-30 имен директорий БЕЗ ОШИБОК так как они прописаны в конфиге ( в полном соответствии с именами директорий в .zmp )

А вот имя директории по-умолчанию равное имени zmp, но с возможностью юзверю его поменять, я вполне могу пообещать. Тоесть, если чувак просто жмет экспорт, то оно экспортнется в нужную папку. Но вот если он начнет его руками править, то тут уж извините.

И в этом случае очень бы помогло именно некое логическое имя (идентификатор) источника передаваемое при экспорте.Подозреваю что же самое имя(идентификатор) источника потребуется и интерфейсу хранилища тайлов Я вобщем то готов согласиться на GUID источника... (ну придется мне держать мапу GUID->базовое имя файла)Единственно не хочется что-бы GUID этот менялся при каждом чихе (например подправили урлу гуглового спутника, GUID останется старым или тоже изменится? )

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

[vmax]

Именно что философский. Я против любых излишеств. В этом типе плагинов будет передаваться только инфа о имеющихся тайлах.

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

А экспорт из нескольких источников это задача SAS.Планеты.
Когда-нибудь список заданий появится.

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

А вот имя директории по-умолчанию равное имени zmp, но с возможностью юзверю его поменять, я вполне могу пообещать. Тоесть, если чувак просто жмет экспорт, то оно экспортнется в нужную папку. Но вот если он начнет его руками править, то тут уж извините.

Мне кажется что это гораздо сложнее будет реализовать чем передать ID источника.
Хотя-бы потому что типовая задача экспорта это экспорт нескольких источников в одну и ту-же базовую папку.
С наличием параметра идентификатора источника интерфейс один в один ляжет в русло уже существующего функционала экспорта. Без него будет сбоку-припеком.

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

Вижу что не убедил. Но очень старался.
Может тогда сразу перейдем к обсуждению интерфейса IExportBulkToFolder ?
С нетерпением жду PlaginAPI... а пока курю Delphi

[vdemidov]

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

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

Именно, но при этом вы окажетесь пред фактом что данный интерфейс уже не пригоден.

Как раз данный тип и будет максимально пригоден.

Хотя-бы потому что типовая задача экспорта это экспорт нескольких источников в одну и ту-же базовую папку.

Кто вам такое сказал? Даже в вашем случае это не совсем так. Точнее вы то делаете экспорт в одну папку, но идеологически правильнее было бы разнести в разные.

С нетерпением жду PlaginAPI... а пока курю Delphi

Ну поверьте, что написав объекты с интерфейсами, которые я описал в заголовочном посте будет очень просто сделать готовый работающий плагин. На самом деле юниты, которые будут использоваться в SDK уже готовы. Там нет ничего слишком умного или сложного. Но я опять же не хочу связывать себя обязательствами преждевременно. Вдруг решу в последний момент попереименовывать все методы? Или переставить их порядок? Или часть удалить.