Implement a way to queue message to all listeners

[GoogleCodeExporter]

every process, message managers will need to know all available message 
receivers and their 
associated groups for this to function

Original issue reported on code.google.com by bigjh...@gmail.com on 9 Nov 2007 at 9:48

[GoogleCodeExporter]

Original comment by bigjh...@gmail.com on 9 Nov 2007 at 9:49

• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

also, it seems like if message managers can know about all available receivers, 
then we wouldn't need to have a 
tick method, and messages could immediately be delivered. this could make 
pysage a bit more "real time"

Original comment by arsch...@gmail.com on 9 Apr 2009 at 4:42

[GoogleCodeExporter]

arschles, if I get what you are saying, the "trigger" method would be the "real 
time"
version of "tick".  "trigger" would not be available for actors that are in a
different process.  There may be a future possibility of a "deferred" concept, 
which
is a promise to return a result, like what's implemented in "twisted".  But 
that will
still be asychronous.

Original comment by bigjh...@gmail.com on 9 Apr 2009 at 5:21

[GoogleCodeExporter]

yea, something like that. although it looks like the trigger method is 
synchronous.

what I'm proposing is that we have a queue_message method that: (a) is 
asynchronous and (b) doesn't require that you call tick() later. This could 
implement a deferred concept 
(as you said, like twisted; also like java.util.concurrent.Future<T> and C++ 0x 
futures), but I personally think that it would make more sense to just send 
messages 
asynchronously and have the sender forget about them. this increases the 
probability that client code will be written that isolates two workers from 
each other as much as 
possible.

it would be the receiver's responsibility to do some work and send a reply 
message back when it's done. the future construct could be built on top of that 
primitive, then.

the Google Gears WorkerPool API has something like what I'm proposing: 
http://code.google.com/apis/gears/api_workerpool.html

Original comment by arsch...@gmail.com on 9 Apr 2009 at 6:01

[GoogleCodeExporter]

Ah, I think I know what you are saying.  

Look up these methods 

queue_message_group (IPC)
send_message (network)

in the API:
http://bigjinfo.com/pysage/pysage.system.ActorManager-class.html

These methods do send the serialized message right away without waiting.  The 
queue
in a local process is used only for incoming messages.  Outgoing messages to 
other
processes and networks are sent right away.  

Having said that, "tick" is by which pysage polls for incoming data, so the 
receiving
end will need to call "tick" to receive that data.

Original comment by bigjh...@gmail.com on 9 Apr 2009 at 6:29

[GoogleCodeExporter]

makes sense. very cool. two more questions:

(1) why are the network calls different from the IPC equivalents?
(2) is it possible to make it opt-out to poll for messages on the receiving end 
(as opposed to opt-in, which it 
seems to be now)? it could be accomplished with a decorator perhaps.

Original comment by arsch...@gmail.com on 9 Apr 2009 at 6:36

[GoogleCodeExporter]

Good questions, I replied to this in the mailing list.  Let's discuss there.

Original comment by bigjh...@gmail.com on 9 Apr 2009 at 7:11