On Wed, Feb 11, 2004 at 09:54:24AM -0800, Scott wrote: > > >> > >>Not everything needs to be an event, or so Rocco once told me. > > > > > >True, but POE is nice because you /can/ make everything an event, if > >you so desire. > > > Yes but this still isn't an arguement for inter-session calling, and in > addition, it also not an arguement against POE::Session->call(). Just > because you /can/ make everything an event, doesn't neccesarily mean it > should be given or even encouraged that you should make things which > rely on a synchronous state and then shoe-horn them into an asynchronous > framework.
The other side of this coin: Just because synchrony is bad doesn't mean it should be impossible. Languages that make bad things impossible are not much fun. Consider Pascal. And POE should be fun. Further, as Jonathan, Nick, and Andrew have said, the badness of the feature doesn't eliminate its utility. And the feature seems very useful, and very well-used. As much as inter-session call gums up the current and future works, I think it should stay. 1. Deprecating it will be a long, drawn-out ordeal. At least a year in the making. Such a fundamental deprecation would severly delay the 1.00 release proposed in a recent article on this very list. 2. POE::Component::IKC---and every other inter-process messaging service---is not required to support inter-process call() even if POE does. Therefore, call() across a wire is a moot issue. 3. When POE acquires thread support, we might be able to run an inter- process messaging service in a separate thread. If we remove inter- session call, we'll only need to add it back later if we want to support synchronous RMI. 4. The Session->call() syntax, whether it's call() or invoke() or do() or something else, does not prohibit inter-session call() anyway. It does, however, imply that inter-process call() is not available, since you can't refer to the remote session by a registered name. That seems more limiting than the current scheme. My previous questions stand; there seem to be design options where performance is improved without compromising POE's flexibility. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
