Complications
automagic
In my experience, all forms of automagic and DWIM should be viewed as fraught with peril. Implicit behaviour can lead to suprises.
keepalive
What if the connection closes? Should we throw away all the state we have set up regarding that session (proxy sessions, etc). Or do we try to reconnect, saving up messages that are routed to that kernel? (with timeout, of course)
Even nuttier: how about saving Messages to some backing store (disk, DB, ...). That way even if the daemon dies, when it restarts it can reload the Message and try to send it again.
Postbacks
By Postback, I mean something like
Source
$poe_kernel->post(session2=>'something', {
TellMe=>'favorite colour',
Answer=>'query'});
$heap->{$id}={event=>$_[ARG0]{Answer}
session=>$_[SENDER]->ID};
$poe_kernel->post($heap->{$id}{session}, $heap->{$id}{event});
Because POE uses a simple string for Event names, and sessions assume they postback to $_[SENDER] and that they can keep $_[SENDER]->ID around, it is next to impossible to have transparent IKC post backs!
IKC1 attempts to remedy this by creating a temporary proxy $_session for [SENDER], but it needs to be GCed at some point. $_IKC1 does it after the destination state is finished. In practice, this isn't long enough. Also, creating a session per message is wasteful, though all messages from a given session could they could be aglomerated.
- $_[SENDER]->ID would return a tied scalar. In it's DESTROY, you shutdown the proxy session. We have to track when the source session disapears and shutdown the proxy session. This is transparent, but can fail in hard to diagnose ways. Say if ID is then only used as key to a hash.
- $_[SENDER]->ID is a tied scalar. It contains information that will allow POE (via our hooks into POE) to resolve to the remote sender.
But then, what about
$ses=$poe_kernel->ID_id_to_session($_[SENDER]->ID);
and other, related functions?
- Source session declares itself as "postback-able" to the the destination kernel. That kernel then creates a proxy session and this is used as $_[SENDER].
This requires extra coding at the source end.
- Source session has to create a special "postback" object. This postback object acts as the 'event' that destination will hold onto. We then have hooks in the kernel which allow us to resolve that event into it's proper destination.
This requires extra coding at the source end.
If we can't control the source end, we could do an additional trick. We would have to keep a list of all event parameters that are events and then turn those parameters into the special postback object when we marshall the parameters.
This last requires extra coding on either side.
In fact, I think I like this last idea best.
Save this on Delicious