Собственное Air-постбилд приложение для FD
 

Есть приложение написанное на Air, которое модифицирует скомпилированный swf-файл внося изменения в байткод и теги. Что-то наподобие Azoth(который делал инъекции оптокодов Alchemy), но для ливкодинга. Вопрос заключается в том, как запускать этот патчер после того как FlashDevelop собрал файл, но ещё не запустил ADL или FlashPlayerDebugger?

1. Самое очевидное - установить его как постбилд-приложение в настройках проекта, но поскольку оно должно висеть в памяти и просто обрабатывать собранный файл, то нет смысла вызывать его каждый раз заново.
(если я правильно понимаю, что FD продолжает свою работу: вызов следующих постбилд-приложений после того как постбилд-приложение завершилось или после таймаута примерно в 15-20 секунд)

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

3. Есть вариант, что FD запускает пустое приложение-заглушку, которое будет связываться с приложением-патчером и завершится тогда, когда получит него код окончания работы. Таким образом второе висит постоянно запущенным, а приложение-заглушка вызывается после каждого постбилда и вырубается получив ответ от патчера.
Этот вариант представляет мне самым рациональным.
Но здесь есть проблема - связь заглушки и патчера. Через LocalConnection - не уверен, что надёжно и быстро, через сокеты - разумнее, поскольку сам патчер уже является AirServer (см. библиотеку https://github.com/wouterverweirder/AIR-Server ).

Иногда самое очевидное это и есть самое верное. есть задача вносить изменения после компиляции, есть триггер вызова задачи - заверение компиляции, там и нужно выполнять. еще я бы не стал это приложение-патчер распространять как air (чтобы не устанавливать и потом в системе искать через переменные среды и тд), сделай просто bat/sh файл который запускает swf приложение через adl -nodebug, так как это просто утилита которая должна распространяться вместе с проектом.
Если есть задача модифицировать в процессе работы приложения, запускай патчер вместо основного приложения где в аргументы передавай что за приложение нужно запустить и которое нужно слушать (как делают fdb/gdb), где сигналы передавай через trace и слушай output

А вообще писать сервер на Air плохая идея, есть кучу других эффективных технологий С++/Python/Java/C#/nodejs и вот почему:
- нет нормальной многопоточности
- работает только под win и macos
- оверхед на обработку запроса, так как он обрабатывается в общем цикле, а не в момент когда он пришел
- ограничение по памяти (нет x64 версии и для air непонятно почему максимум получается выделить 1.5 гб)
- нет контроля извне (системные сигналы)
- avm в 3-10 раз медленнее нативного/jit кода
работать-то будет, но зачем? на крайний случай если уж очень хочется писать на as3 сервер и ничего не хочется другого изучать, то есть nodeas и redtamarin