Re: [binarycloud-dev] Inter-module communication issues

[alex b. <en...@tu...>]

> $package.mod_name->method1()

That can be achieved with your "tag" patch to Page.
I am suggesting something different, which would be designed specifically to
manage communication between modules and probably from the outside world as
well.

> 1)  The programmer could insure that a particular module
> would be the communicant, even though there were multiple
> copies of of the module.

Correct.

> 2)  It seems that this mechanization could be "in parallel"
> to any other scheme adapted, adding flexibility.

Correct.

> 3)  Administration may be difficult, as names would
> have to be kept track of.

This is a major disadvantage, in my view.

> == Dynamic Discovery ==
> This implies that after all the modules have been collected,
> they are "registered" somehow by the Message Manager.  Then,
> a general module wants to do a call to
>
> $package.mod_name->method()

No.
MessageManager would be responsible for keeping messages, not keeping track
of modules. It would record the source of the message, and make it available
to all other modules if they so desire.

Messages would be "get" and "set" by modules, and the ModuleManager would
serve as the access point.

> This is kind of analogous to an RPC call.  This could get
> complicated.  Imagine if you had two drone modules, each
> holding a dataset from different DB.TABLE's.  Somehow,
> the caller using the dataset from the first Drone Module
> would need to mark the class "busy", reflecting the idea
> that I am not finished with this data, go away.  The

That concept would not exist because of load order. All of this execution is
linear, we don't have memory resident processes doing checks on things, etc.

That means you can get, and set a message, but you can't "wait" until you
see one.

> 4.  Give me a "handle" to the FedEx tagged module,
> and when I get it, I ask the FedEx module
> how much it costs for a 5 lb package
> between ZIP_1 and ZIP_2.

While you could do the above, that kind of thing is very much the domain of
libraries.

Modules should need to communicate only data to each other - and while a
"network" or method calls is certainly possible if we introduce unique names
to the PageDef, It gets very messy very fast.

You can pass data from module to module in the global scope for the moment,
later we'll have a nice way of dealing with "array traffic" in the system -
but even that should be relatively simple.

As far as modules making complex references to each other at runtime, while
it is certainly possible, I don't see a use for it. Many of the functions
that would be supported by such a system are better off as libraries used by
a module to construct a chunk of presentation.

_a