I've been asked a question about DDE in EG on XMPlay thread, which brought some ideas about EG connectivity architecture. Please do not mind the language that I might use freely - these ideas are not even suggestions, just thoughts (nothing about admirable authorship and community or life - just platonic ideas).
I remembered a list of communication technologies that facilitate interactions between software/hardware applications that have relation to Windows OS:
@@(SSL), HTTP, WebDAV, RSS, XMPP, SOAP, REST, MQTT, SMTP, etc, etc, etc.
WM (Windows Messages)
@Keyboard, Mouse, System & custom (User) events
COM (Component Object Model)
@OLE et al.
@execution, parameters, standard streams, environment vars
@TIME, serial int., file system, sound mixer, registry, ODBC, monitors: file system, processes, performance, PnP, etc., printers spooler, user logon, booting, etc.
Hacks (good ones)
@windows properties, process memory read
@images, sound, text, speech, video/animation/OSD
First idea is the classification/ordering (e.g. for plugins' board if ever).
Second - horizon for dev: where do you want to go tomorrow?
Third. Adherence to Pipeline paradigm (Channel, MOM, etc.). Of course EG's center of gravity is OS Services, but its nature is to be heterogeneous (diverse). To embrace Pipeline paradigm may mean to fully realize Ghost nature. Where EG (a lot of its plugins) is lacking?
- Systemic curatory approach on the above grounds (e.g. each technology requirements definition (or dev. to the test) by collective).
- Mixing of a GUI art with the protocols given by standard (e.g. idiomatic web server instead of HTTP CGI adaptation).
- Asymmetry between consumer end (automatic EG event creation) and producer end (access to EG events from without) implementations (i.e. virtually nonexistent pull interface (vs. push) of the producer).
I am perfectly aware that it may be rightfully objected that:
- If I know what to do, I better do it myself and not telling others.
- EG is one of Plugin architecture.
- EG is versatile as it is and GUIs is never an obstacle.