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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Alex:

I just want to put down here some thoughts for rumination.  I
am rather intrigued as to what is in your mind as to how
the Message Manager would work.

Now, any Message Manager only has so much information to
work with to find/identify/advertize other modules in
the set.  I see problems, from my perspective, because
it seems, to me, that I can almost defeat any unique way to
do this, with an example.

	== Logical Notation ==
Logically, it would be nice that if a module wished to
talk to another, something like this would be possible,
in a kind of logical notation:

	$package.mod_name->method1()

ADVANTAGES: 1) the instigator of this
communication would not have to know anything about
where that module is in $bc_page.  That means that
new $bc_page's could be ripped and and modules
added/rearranged and the ensemble would not break if
package.mod_name is somewhere in the tree.

DISADVANTAGES:
1)  This would not allow multiple copies of the same
package.mod_name.   I can imagine an advantage of having
a module that gets the data dictionary of a particular
DB.TABLE while another module gets the data dictionary
of DB1.TABLE1.  Or one module goes and SOAP's to some
site and another copy is told to go SOAP to another
site.  Neither of the modules would have any Output.
In my mind, I call these Drone Modules, they do a
job, but do not print to buffer.
2)  Multiple copies of the same Drone Module could only
be distinguished by sequence of appearance in $bc_page,
which I don't like, because that order may change often
if other modules are added during development up front,
ruining the hard-coded mapping.
3)  The package "name" is really a directory name,
and everything would break if a directory were renamed.
This is probably unlikely in real life, as it would
be a no-no, or a major decision.

	== Tag Notation ==
The programmer could identify any module by a tag to
guarantee that it will be the only one talked to
when the tag is used for selection.

ADVANTAGES:
1)  The programmer could insure that a particular module
would be the communicant, even though there were multiple
copies of of the module.
2)  It seems that this mechanization could be "in parallel"
to any other scheme adapted, adding flexibility.

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

	== 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()

and the general module is guaranted that this will be found.
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
Message Manager would go look for the "next free" Drone
Module, and if it is not "busy", runs the method or
data retrieval through, marks the module "busy" until
the caller "frees" it.  Or, the caller just has to insure
he doesn't destroy data he doesn't need, dispensing with
this "busy" business.  (One can get too sophisticated)

LOOK, I AM ONLY THINKING OUT LOUD HERE.

What I would love to have is ability of loading multiple
copies of a Drone Module that talk/fetch to, say, any
database accessable in the world.  I would like to
ask the Message Manager

1.  Give me a "handle" to an ODBC Drone Module and
	when I get it, I do, logically, connect
	to this URL/database and get a certain dataset.
2.  Give me a "handle" to a MySQL Drone Module and
	when I get it, I do, logically, connect
	to the local MySQL database and get some
	dataset as a function of some data that I
	got in 1) above.  Now I do what I want
	to do with that data, and "release" the
	two Drone Modules.
3.  Give me a "handle" to the module tagged
	"ZipCodeGIS", and when I get the handle,
	I can fetch the latitude and longitude
	of a Zip from the embedded lookup table
	in the module.  Since there is no concept of
	a lookup table being busy, nothing is
	required to mark it busy.
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.
5.  Give me a "handle" to the Hurricane tagged module,
	and when I get it, I pass in an array of
	tuples of time/lat/long/and the Hurricane
	module fetches a map of the Atlantic Ocean
	and draws a spline of the hurricane path
	with GC and deposits this updated hurricane
	map at some standard place. 

and so on...

So in the above, I don't want to worry about:

1.  Where a particular type of (Drone) module lives
2.  I either get the reference from the Message Manager
	or, that there are none available, and I get a fatal
	error.  Better yet, if none are available I
	import() one on the spot since it was not known
	apriori how many I would need (this implies being
	able to "force" another import, a biggie thingy.)

This implies that I can write a "Queen Bee" module that
is the glue, and does the Output.  If I need another
task to be done, or another copy of a data fetching
and holding module, I add a couple of lines to the
XML and re-rip...  

LOOK, I AM ONLY THINKING OUT LOUD HERE.

Maybe I am stretching the functionality you anticipated.
All the above is just food for thought.  You can see
that I am a bit facinated by "Drone Modules" that do a task
but have no output.

	* Ode to BC *
I abide my time,
By adding a line,
To my un-ripped XML,
All other ways can go to hell.

_jef

-- 
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722