On 21-Jun-2001 Rocco Caputo wrote:
> On Thu, Jun 21, 2001 at 04:55:46PM -0400, [EMAIL PROTECTED] wrote:
> 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.
Oh. True. Hadn't thought of this.
> 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.
Postbacks use closures and coderefs, objects that don't travel well.
B::DeParse won't save us here, because the far end might be perl 5.004...
or a completely different language, eventually.
> 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.
Actually, I dove into IKC with very little research :) I'm making it all
up as we go. I suspect a little research would help, yes. Got pointers?
>> 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.
It *is* your POE::Message... only I thought you called it POE::Event.
BTW, starting to call events messages would be a Good Thing, imho.
> You're the unofficial interoperability (i14y?) pumpking, so I
> thought I'd run it past you first.
Please implement. I love it.
> 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.
This I don't grok... We'd still need ARG0...ARG9... unless we move all
the POE stuff into another array (a bit like HTML::Mason does).
>> 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.
The publish/subscribe mechanism aleaviates most need for this (otherwise
I would have required said hooks long ago). However, those hooks could
come in very handy.
>> 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.
I agree this would be a good idea.
> Cue the pitchforks and torches.
yield() is misnamed!
/me runs, ducks and hides.
-Philip
