-------- Original Message --------
From: - Wed Feb 11 09:45:37 2004
X-UIDL: +G;"!pZb"!T`G!!<[*!!
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <[EMAIL PROTECTED]>
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: from x1.develooper.com (x1.develooper.com [63.251.223.170]) by debian (Postfix) with SMTP id 8C08662D01 for <[EMAIL PROTECTED]>; Tue, 10 Feb 2004 21:42:59 -0800 (PST)
Received: (qmail 3282 invoked by uid 225); 11 Feb 2004 17:41:21 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 3249 invoked by alias); 11 Feb 2004 17:41:10 -0000
Received: from [205.188.139.136] (HELO imo-d20.mx.aol.com) (205.188.139.136) by la.mx.develooper.com (qpsmtpd/0.27-dev) with ESMTP; Wed, 11 Feb 2004 09:41:10 -0800
Received: from [EMAIL PROTECTED] by imo-d20.mx.aol.com (mail_out_v36_r4.12.) id f.1ef.18cbb617 (4238) for <[EMAIL PROTECTED]>; Wed, 11 Feb 2004 12:41:01 -0500 (EST)
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 11 Feb 2004 12:41:01 EST
Subject: Re: POE::Session->call()
To: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1076521261"
X-Mailer: 9.0 for Windows sub 450
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on x1.develooper.com
X-Spam-Status: No, hits=-4.6 required=8.0 tests=BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.63
X-UIDL: +G;"!pZb"!T`G!!<[*!!
FWIW,
I can see the need for using call between sessions...
For example, lets say I'm modelling the behavior of a series of servers and processes in POE. When certain states are achieved, I yield other event handlers in chains to determine the true state. Each session then becomes an "envelope" for a given managed object.
I may have one session tracking a data store of some sort and another tracking an apache instance. Because they are interrelated, I need to be able to check on the status of another session and potentially post events to that session in near real time.
Just a thought...
Dougie!!!
In a message dated 2/11/2004 5:35:03 AM Eastern Standard Time, [EMAIL PROTECTED] writes:
Nicholas Perez wrote:
> Okay, I am no POE internal genius, and perhaps I am using call()
> inappropriately (inter-session), but I find a lot of convenience in
> using a separate Session to hold data that needs to be
> synchronized/serialized.You should be using an object or global structure, or the heap.
> Not only that, that there is also even greater convenience in that
> fact that call() returns something.The proposed Session->call() method still provides the return value of the state invoked.
> I don't need to provide or kludge around with return events for data
> that I need immediately for critical paths. Now some may argue
that I
> just need to maintain a separate class or object and make method
calls
> to that to access that data, but then I run into the problem of
making
> sure all the Sessions that I want to be able to access that object,
> all have that object.Simple! Create the object in the package you create your session in. If you need various sessions to use the same data, then make your
object
store its neccesary data in a package global, so your object has
object-persistent data, that is, data for each instance of itself in
its
blessed referrence, any data that needs to not be on a one-on-one basis
and must be accessable from all instances of the object, you keep in
globally scoped package variables.
> With a stand alone Session, I can simply reference it by its
alias and
> make call()s to it.Thats slow ;)
> Now maybe the negatives outweigh my laziness, but in my not so
> knowledgeable opinion, having a specific Session filled just with
> synchronized or critical functions just makes sense in the cases
that
> I have applied it.Not everything needs to be an event, or so Rocco once told me.
>
> Just my two cents on the matter. I found a practical application for
> what everyone seems to call ugliness.The only real problem with trying to design an efficient program the way you mentioned is there is alot of imposed context switching by your design that could be avoided. Its all behind the scenes and happens within the POE::Kernel itself, so this overhead is imposed by the design itself.
If you're really only storing data, you really should use an object OR package in the ways I mentioned above. Atleast, if you have any desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing inter-session calling all together. I found the idea on the wiki. Now I'm not gonna name names, and I'm not gonna drag others in, because I am a proponent of the idea. I think inter-session calling breaks POE Design patterns. Forcing inter-session communication to be done via post()ing helps force people using the POE Framework to let POE do its thing, and stops people from doing things like creating sessions just for the sake of creating sessions.
- Scott
