On Thu, Jun 21, 2001 at 04:55:46PM -0400, [EMAIL PROTECTED] wrote:
> I hate call(). I really do. It makes code un-POE-like. And it can't
> work w/ IKC. However, it's really the best way to get an answer back. In
> IKC, you have to do $kernel->post(IKC=>'call', $specifier=>[params],
> 'callback_state') but this isn't compatible with session subscription.
call() sucks, but it lets wheels pass on their synchronous input
events to the sessions which own them. As far as I know, that's the
only valid reason to use it.
Not entirely true. I use it extensively in the crossword server xwws
(somewhere at poe.perl.org), but I'd rather not have had to. Now that
postbacks exist, the mere act of sending an event can keep the sender
alive at least until it's delivered.
Although postbacks across the inter-process boundary are going to fail
unless the gateway component holds onto them.
Speaking of IKC woes, RPC and cluster computing background papers may
explain some of the hardships you have/will encounter. I suppose
you've already done the research, but I'm suggesting on the off chance
it could help.
> So, how about also allowing a hash ref... or POE::Event object as a
> specifier for event addresses?
> {
> to=>'some_session/some_event',
> sender=>$_[SENDER],
> reply=>'callback_event'
> errors_to=>'error_event' # temporary monitor
> }
This looks like the POE::Message prototype I sent you a week or so
ago. You're the unofficial interoperability (i14y?) pumpking, so I
thought I'd run it past you first.
This would also eliminate ARG0..ARG9 for many high-level things, which
would make mjd happy. His comments on the subject prompted the
ARG0..ARG9 depreciation in the TODO file (still only in the "hey, this
could be a good idea" phase. no scary breakage yet!), and ultimately
POE::Message.
> of course, all of these could be IKC specifiers.
POE::Message would also work in stock POE. I imagined adding hooks to
the alias/id resolver to pass messages to unknown destinations to a
resolver/gateway component, if such a beast was loaded.
> This way, we can ignore call() when playing with IKC. We can deprecate
> call(). We can live free!
Can't depreciate call() in the general sense, sorry. Wheels need it.
But as Artur has suggested before on the topic, we can depreciate and
prevent it from working on any other session but the current one.
Basically we'd remove the SESSION parameter and have it default to the
current one.
Cue the pitchforks and torches.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
