On Wed, Feb 11, 2004 at 12:41:19AM -0800, Scott wrote: > In addition, there are several optimizations that cannot be made from > POE::Kernel->call, > one is that due to the current interface rules we must allow > Kernel->call() to be given > the arguement of a session id or alias. For this reason, we must > resolve the first arguement > to the appropriate session. Thats not the case with adding a call() > routine to POE::Session > as we are guarenteed a POE::Session object. So we simply cannot do the > same amount > of optimization.
By the way, your mailer and editor are fighting. It looks like your editor writes lines longer than your mailer likes, and your mailer's wrapping them poorly out of spite. What if there were a Kernel method, similar to yield(), that assumed (and called upon) the current session? What might that be called? > Aside from that, there was a second rational behind > POE::Session->call(), and that is, to provide an interface for a higher > level of event routing. One that bypasses the POE::Kernel entirely, but > still respects ->state() changes. Its a middle ground between invoking > the code reference the state actually resolves to directly, and actually > throwing an event to the Kernel. This sort of higher level might be inappropriate in a low-level "continuation" object like Session. Maybe it belongs in Component, or some other higher-level construct? > The idea being optimizations such as, switching the event handler via > POE::Kernel->state() would still work, and we still have the advantage > of a live, active @_ being built by POE::Session's _invoke_state(), but > since we're not actually an event we don't need the FIFO, and since > we're obviously not changing sessions we dont need GC'd, and since we > know who we are we dont need any resolution. This makes doing your > event routing entirely external from POE less favorable for components, > for instance. Where a common practice is currently to accept code > references in the constructor. Here we could actually just as easly, > without a great efficiency loss, accept event names and allow the user > to contribute to the session's construction. This adds, in addition to > the above noted benefits, the ability to easily design state-type free > components. In which case I mean, a component that simply accepts the > same inline_state, package_state, and object_state arguements that > POE::Session's constructor does, and allows the user to build their > session's events in which ever way they see fit. Without being horribly > inefficient by say, making every single little tiny event hit the fifo > or traverse _dispatch_event in any way. > > Some of us try to build our components to be as efficient as possible, > doing things like multiplexing our sessions to avoid needing a seperate > session for each task, and routing our interface events with code > references instead of POE itself. This makes it easier for us to > provide beautiful interfaces to components that are still relatively fast. POE does involve overhead, and overusing it will make your software slower than it needs to be. A lot of people don't realize this right away. I think it's because there's not enough documentation covering POE design patterns. I've watched a lot of design patterns emerge from the way people write POE programs. Heck, I've pioneered some of the worst of them. IKC's publish/subscribe model, which works across networks. The plain callbacks of POE::Component::Server::TCP. The message-based subscribe model in POE::Component::IRC. The post/postback model in POE::Component::Client::DNS. The class- and object-based models I've used in contract work. I guess I don't have a point here. I'm just acknowledging yours. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
