EG Pipeline

Got a good idea? You can suggest new features here.
Post Reply
obermann
Posts: 8
Joined: Sun Jan 13, 2019 3:54 pm
Contact:

EG Pipeline

Post by obermann » Thu Jan 24, 2019 9:13 pm

THIS IS NOT A REQUEST!

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:

IP
@TCP, UDP
@@(SSL), HTTP, WebDAV, RSS, XMPP, SOAP, REST, MQTT, SMTP, etc, etc, etc.

CIFS (SMB)
@Named Pipes
@@WinPopup

WM (Windows Messages)
@Keyboard, Mouse, System & custom (User) events
@@DDE, Clipboard

COM (Component Object Model)
@OLE et al.

Shell
@execution, parameters, standard streams, environment vars

OS Services
@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

Direct
@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?
  1. Systemic curatory approach on the above grounds (e.g. each technology requirements definition (or dev. to the test) by collective).
  2. Mixing of a GUI art with the protocols given by standard (e.g. idiomatic web server instead of HTTP CGI adaptation).
  3. 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).
Maybe you've already guessed that a secret behind these ideas is the marked distinction of connectivity plugins vs. concrete/finite appliances control plugins.

I am perfectly aware that it may be rightfully objected that:
  1. If I know what to do, I better do it myself and not telling others.
  2. EG is one of Plugin architecture.
  3. EG is versatile as it is and GUIs is never an obstacle.
Thanks for your kind attention.

Post Reply