Total Commander

[Lev]

Мое видение внутренних принципов работы контентных плагинов (или Почему не развивается ScriptContent Plugin?).

Написав несколько контентных плагинов, я составил некоторое свое представление (возможно неправильное) о необходимых принципах их работы.

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

Место хранения полученной информации - полученная информация может храниться во временной директории системы (или поддиректории в ней), в директории плагина, в каждой из просматриваемых директорий (как description.ini). Желательно иметь возможность выбора между вариантами места хранения информации. В настройках плагина должен быть соответствующий изменяемый ключ.

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

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

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

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

Реализация данных принципов работы, по моему мнению, позволит забыть о моем устаревшем ScriptContent Plugin'е
Естественно могут быть и плагины время получения информации которыми пренебрежимо мало и все эти ухищрения с сохранением-чтением инфы им не нужны.

-------
Попытаюсь обрисовать ТЗ на простейший плагин читалку полей, файлы будем создавать внешними методами
plugin.ini - хранится в директории плагина, наверно, для простейшей читалки можно обойтись и без него
[Options]
InfoFileName = "content.inf"

[content.inf]
Fields=10 'для данного имени инфофайла зарезервировано 10 полей
StoragePlace = 1 'храним инфофайлы в каждой из директорий
StorageMethod = 1 'храним plain text
Verification = 0 'не проверяем свежесть информации и не перезаписываем её
PlainTextSeparator = "|"

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

---
Спасибо за внимание
lev