RFC - implementing callbacks

[Gary Stainburn]

Hi folks,

Thanks to previous threads on this list, I'm making pretty good progress on
what is my first OOP project. The improvements I've made after feedback are:

* logical bounderies between containers and contents (sub-classes)
* nicer interface functions
* (starting to use) named parameters, with option to still use positional
* Classes only know about themselves and sub-classes

I now have the following structure (roughly). Trainset is the top level class
and is the container for everything .

Program
|->Trainset (everything)
|-> Box ( individual signalbox)
|->Gantry ( signal gantry)
| |->Signal
|->Tcb (Length of Track Circuit)
| |->Track (single length of track)
|->Lever (lever in signalbox)

One of the points made in the previous threads was that there should be no
need for sub-classes to have a link back to it's parent, and through the
correct splitting of functions (inter-instance in class, intra-instance
within container) I've done this okay.

My problem is now:

I need to be able to pass to the Trainset instance a ref to a callback within
Program (to refresh a PerlTk window, or to send a signal to a model railway
controller). This callback then needs to be triggered by the Trainset
instance itself, but also from Signals, Gantries, and Tcbs.

Other than going back to holding a ref to the Trainset instance, or worse
still, copying the ref to the callback to every object, how can I do this?
--
Gary Stainburn

This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000

[James Edward Gray II]

On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:

> Hi folks,

Hello again.

[snipped history]

> One of the points made in the previous threads was that there should
> be no
> need for sub-classes to have a link back to it's parent, and through
> the
> correct splitting of functions (inter-instance in class, intra-instance
> within container) I've done this okay.

Let's not say you should "never" have links back to the parent object.
I've seen places where it made fine sense. I actually have I server
I've been working on that does this. Individual connections keep a
link to the main server, to inform it of changes in their status, based
on network reads/writes and to access server wide functionality, like
logging.

Generally though, what you say is a good rule of thumb.

> My problem is now:
>
> I need to be able to pass to the Trainset instance a ref to a callback
> within
> Program (to refresh a PerlTk window, or to send a signal to a model
> railway
> controller). This callback then needs to be triggered by the Trainset
> instance itself, but also from Signals, Gantries, and Tcbs.

I should warn that I have no familiarity with TK, though I do have
general GUI toolkit knowledge.

The above sounds backwards to me. Why should Trainset objects be tied
to their interface? That limits their usefulness. The interface is an
interface for representing Trainset objects, right? Well, then it
makes sense for that interface to maintain a link to the Trainset
object it is currently representing, right?

I assume TK is event driven. So, when an event happens, I would think
you would access the Trainset in the event handler, make changes and
update.

Now, if the Trainset object is somehow being modified by an outside
source (the model controller you mention perhaps), things get a little
trickier. You could always poll the Trainset object every so often to
see if it has changed. Polling is generally considered bad though, so
possibly better would be to have the code that is somehow changing
Trainset, to call an update routine on the interface. If controller
signals are just another event being handled by the interface and the
interface is already keeping track of the Trainset, as I believe it
should, the controller event handler can pass along the change and call
for a refresh.

Be aware, if the GUI allows changing the Trainset and the model
controller is changing the Trainset, you make have concurrent access
issues to deal with.

Well, maybe that will give you some new ideas.

James

[Wiggins D Anconia]

> On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:
>

> > Hi folks,

>
> Hello again.
>
> [snipped history]
>

> > One of the points made in the previous threads was that there should
> > be no
> > need for sub-classes to have a link back to it's parent, and through
> > the
> > correct splitting of functions (inter-instance in class, intra-instance
> > within container) I've done this okay.

>
> Let's not say you should "never" have links back to the parent object.
> I've seen places where it made fine sense. I actually have I server
> I've been working on that does this. Individual connections keep a
> link to the main server, to inform it of changes in their status, based
> on network reads/writes and to access server wide functionality, like
> logging.
>
> Generally though, what you say is a good rule of thumb.
>

> > My problem is now:
> >
> > I need to be able to pass to the Trainset instance a ref to a callback
> > within
> > Program (to refresh a PerlTk window, or to send a signal to a model
> > railway
> > controller). This callback then needs to be triggered by the Trainset
> > instance itself, but also from Signals, Gantries, and Tcbs.

>
> I should warn that I have no familiarity with TK, though I do have
> general GUI toolkit knowledge.
>
> The above sounds backwards to me. Why should Trainset objects be tied
> to their interface? That limits their usefulness. The interface is an
> interface for representing Trainset objects, right? Well, then it
> makes sense for that interface to maintain a link to the Trainset
> object it is currently representing, right?
>
> I assume TK is event driven. So, when an event happens, I would think
> you would access the Trainset in the event handler, make changes and
> update.
>
> Now, if the Trainset object is somehow being modified by an outside
> source (the model controller you mention perhaps), things get a little
> trickier. You could always poll the Trainset object every so often to
> see if it has changed. Polling is generally considered bad though, so
> possibly better would be to have the code that is somehow changing
> Trainset, to call an update routine on the interface. If controller
> signals are just another event being handled by the interface and the
> interface is already keeping track of the Trainset, as I believe it
> should, the controller event handler can pass along the change and call
> for a refresh.
>
> Be aware, if the GUI allows changing the Trainset and the model
> controller is changing the Trainset, you make have concurrent access
> issues to deal with.
>
> Well, maybe that will give you some new ideas.
>

I hate beating a dead horse... but this discussion of your callbacks and
triggering events that are caught by a main controller, is exactly the
type of thing POE was designed to handle. Essentially a central kernel
is running and dispatches events that happen elsewhere in the app to
their event handlers. Which works for gui events as well as other
environment changes (aka like the polling mentioned above). Within
individual object sessions other events can be sent to other sessions in
a callback manner based on the session name through the kernel which
controls all sessions, so keeping objects tied to each other directly
isn't necessary, the running kernel does it for you.

You may also want to check out (not sure if I have mentioned it before)
Event.pm, though I prefer POE's complete buildout....

[url]http://danconia.org[/url]

[R. Joseph Newton]

James Edward Gray II wrote:

> On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:
>

> > Hi folks,

>
> Hello again.
>
> [snipped history]
>

> > One of the points made in the previous threads was that there should
> > be no
> > need for sub-classes to have a link back to it's parent, and through
> > the
> > correct splitting of functions (inter-instance in class, intra-instance
> > within container) I've done this okay.

>
> Let's not say you should "never" have links back to the parent object.
> I've seen places where it made fine sense. I actually have I server
> I've been working on that does this. Individual connections keep a
> link to the main server, to inform it of changes in their status, based
> on network reads/writes and to access server wide functionality, like
> logging.
>
> Generally though, what you say is a good rule of thumb.
>

> > My problem is now:
> >
> > I need to be able to pass to the Trainset instance a ref to a callback
> > within
> > Program (to refresh a PerlTk window, or to send a signal to a model
> > railway
> > controller). This callback then needs to be triggered by the Trainset
> > instance itself, but also from Signals, Gantries, and Tcbs.

>
> I should warn that I have no familiarity with TK, though I do have
> general GUI toolkit knowledge.
>
> The above sounds backwards to me. Why should Trainset objects be tied
> to their interface? That limits their usefulness. The interface is an
> interface for representing Trainset objects, right? Well, then it
> makes sense for that interface to maintain a link to the Trainset
> object it is currently representing, right?
>
> I assume TK is event driven. So, when an event happens, I would think
> you would access the Trainset in the event handler, make changes and
> update.
>
> Now, if the Trainset object is somehow being modified by an outside
> source (the model controller you mention perhaps), things get a little
> trickier. You could always poll the Trainset object every so often to
> see if it has changed. Polling is generally considered bad though, so
> possibly better would be to have the code that is somehow changing
> Trainset, to call an update routine on the interface. If controller
> signals are just another event being handled by the interface and the
> interface is already keeping track of the Trainset, as I believe it
> should, the controller event handler can pass along the change and call
> for a refresh.
>
> Be aware, if the GUI allows changing the Trainset and the model
> controller is changing the Trainset, you make have concurrent access
> issues to deal with.
>
> Well, maybe that will give you some new ideas.
>
> James

When I use Tk to describe an object sytem, I usually make an application-level
object, aware of both the object system and the Tk interface structure, to
control the overall
process. I also make wrapper classes for each major component widget, to manage
its role
in the overall process.

These application-level classes assume the responsibility for being aware of the
various classes
and objects used. Therefore the conceptual classes used to model the problem
need not be
aware of any extraneous factors. They simply need to provide dependable
performance at
their own interfaces, to model their own concepts faithfully.

So far, this approach has worked pretty well. I am able to make major, radical
changes to
individual sections of my program, with minimal impact on other sections.

Joseph

[Gary Stainburn]

On Wednesday 11 Feb 2004 2:54 pm, R. Joseph Newton wrote:

> James Edward Gray II wrote:

> > On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:

> > > Hi folks,

> >
> > Hello again.
> >
> > [snipped history]
> >

> > > One of the points made in the previous threads was that there should
> > > be no
> > > need for sub-classes to have a link back to it's parent, and through
> > > the
> > > correct splitting of functions (inter-instance in class, intra-instance
> > > within container) I've done this okay.

> >
> > Let's not say you should "never" have links back to the parent object.
> > I've seen places where it made fine sense. I actually have I server
> > I've been working on that does this. Individual connections keep a
> > link to the main server, to inform it of changes in their status, based
> > on network reads/writes and to access server wide functionality, like
> > logging.
> >
> > Generally though, what you say is a good rule of thumb.
> >

> > > My problem is now:
> > >
> > > I need to be able to pass to the Trainset instance a ref to a callback
> > > within
> > > Program (to refresh a PerlTk window, or to send a signal to a model
> > > railway
> > > controller). This callback then needs to be triggered by the Trainset
> > > instance itself, but also from Signals, Gantries, and Tcbs.

> >
> > I should warn that I have no familiarity with TK, though I do have
> > general GUI toolkit knowledge.
> >
> > The above sounds backwards to me. Why should Trainset objects be tied
> > to their interface? That limits their usefulness. The interface is an
> > interface for representing Trainset objects, right? Well, then it
> > makes sense for that interface to maintain a link to the Trainset
> > object it is currently representing, right?
> >
> > I assume TK is event driven. So, when an event happens, I would think
> > you would access the Trainset in the event handler, make changes and
> > update.
> >
> > Now, if the Trainset object is somehow being modified by an outside
> > source (the model controller you mention perhaps), things get a little
> > trickier. You could always poll the Trainset object every so often to
> > see if it has changed. Polling is generally considered bad though, so
> > possibly better would be to have the code that is somehow changing
> > Trainset, to call an update routine on the interface. If controller
> > signals are just another event being handled by the interface and the
> > interface is already keeping track of the Trainset, as I believe it
> > should, the controller event handler can pass along the change and call
> > for a refresh.
> >
> > Be aware, if the GUI allows changing the Trainset and the model
> > controller is changing the Trainset, you make have concurrent access
> > issues to deal with.
> >
> > Well, maybe that will give you some new ideas.
> >
> > James

>
> When I use Tk to describe an object sytem, I usually make an
> application-level object, aware of both the object system and the Tk
> interface structure, to control the overall
> process. I also make wrapper classes for each major component widget, to
> manage its role
> in the overall process.
>
> These application-level classes assume the responsibility for being aware
> of the various classes
> and objects used. Therefore the conceptual classes used to model the
> problem need not be
> aware of any extraneous factors. They simply need to provide dependable
> performance at
> their own interfaces, to model their own concepts faithfully.
>
> So far, this approach has worked pretty well. I am able to make major,
> radical changes to
> individual sections of my program, with minimal impact on other sections.
>
> Joseph

I have decided to have limited links to parents, where appropriate. For
example, a signal must be attached to a gantry, the state of the gantry being
the sum of the states of it's signals. It therefore makes sense for the
signals to be able to pass on the state change to the gantry object. The
gantry can then perform a similar action with the Trainset object, and this
call the callback method in the main program.

I plan to follow a system similar to what Joseph has suggested. I plan to
develop Trainset::Tk, which will know how to represent a signal gantry as a
group of Tk widgets. Likewise with lever, TCB sections etc.

I can then simply use a callback method within Trainset::Tk from within the
Trainset instance. This idea I think tidies things up tremendously.

I can understand the point that James made, in that the update of the Trainset
objects is being made by a Tk event trigger, and could therefore simply
update the screen at the same time, e.g. clicking on a lever throws a signal
*and* updates the screen. The problem is that it's not allways possible to
know every object that gets affected - the state of the signal may affect
other objects, such as changing a locomotives state from 'Stopped' to 'Clear
To Proceed'. This is the reason behind needing the callback method.

The other problem mentioned, that of concurrent input from the screen and from
a model railway controller hopefully won't be a problem. Again, I plan on
developing Trainset::Controller, which will be used to both send commands
ands receive feedback. The plan is to have this call a callback method
similar to the one above.

If it does become a problem (I won't know until I start looking at the
interface method, possibly standard serial connection), I will look at POE
but as I said before, I don't want to add to the complexity of the project
until I have to.

The way I'm designing it, I think POE could fairly easily be slotted in at a
later date.

Once again, thanks to everyone for their suggestions.
--
Gary Stainburn

This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000

[Gary Stainburn]

On Tuesday 10 Feb 2004 10:41 pm, Wiggins d Anconia wrote:

> > On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:

> > > Hi folks,

> >
> > Hello again.
> >
> > [snipped history]

> I hate beating a dead horse... but this discussion of your callbacks and
> triggering events that are caught by a main controller, is exactly the
> type of thing POE was designed to handle. Essentially a central kernel
> is running and dispatches events that happen elsewhere in the app to
> their event handlers. Which works for gui events as well as other
> environment changes (aka like the polling mentioned above). Within
> individual object sessions other events can be sent to other sessions in
> a callback manner based on the session name through the kernel which
> controls all sessions, so keeping objects tied to each other directly
> isn't necessary, the running kernel does it for you.
>
> You may also want to check out (not sure if I have mentioned it before)
> Event.pm, though I prefer POE's complete buildout....
>
> [url]http://danconia.org[/url]

Hi,

You're not beating a dead horse, and I haven't forgotten your suggestion.
It's just that last time I looked at POE, I got brain ache.

The other reason I've tried to avoid POE is that I want my package to have as
few dependancies as possible. I intend once it's finished to make it
available for others to use and therefore want the installation to be as
painless as possible.

The only area I'm currently concerned about is the Model radio controller as I
haven't actually had my hands on one yet, and don't know what the
communications methods is yet. If it's something like a standards serial
cable link then I may need to use POE to drive this.

The argument against Event.pm is the same one as POE, but I will look into it
if the need arrises.

Thanks again for your comments.
--
Gary Stainburn

This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000

[James Edward Gray II]

On Feb 12, 2004, at 9:21 AM, Gary Stainburn wrote:

> I can understand the point that James made, in that the update of the
> Trainset
> objects is being made by a Tk event trigger, and could therefore simply
> update the screen at the same time, e.g. clicking on a lever throws a
> signal
> *and* updates the screen. The problem is that it's not allways
> possible to
> know every object that gets affected - the state of the signal may
> affect
> other objects, such as changing a locomotives state from 'Stopped' to
> 'Clear
> To Proceed'. This is the reason behind needing the callback method.

This shouldn't be an issue at all. Remember when we talked about the
Trainset object being an interface to the whole underlying system?
That's to solve exactly this problem, and many others.

Trianset, at any given time, should be able to describe the entire
setup. That's it's job. That's also why the TK widgets, should hold
onto a link to the sucker.

Here's how I envision an event happens: Event handler locates correct
signal box to flip or train to change, however it does that, and make
the change. Event handler calls update/refresh on the appropriate
interface object(s), maybe the whole window. Update/refresh do their
thing and eventually, I assume we end up in some kind of draw/paint
method. In draw/paint we don't care about signal boxes and trains, we
just want to do our job. We pull up our stored link to the Trainset,
and ask it to tell us what it looks like right now. That will of
course include whatever change we recently made to some signal box or
train. When it tells us, we draw that.

Trainset just needs to do its job, which is to worry about Trainset
stuff, not interfaces. We let the interface objects worry about
interfaces and how to display Trainsets, because that's their job.

You're always very quick to resort to serious cross linking in your
discussions. This will only increase your pain, remember that. Heck,
isn't that the main reason you keep shooting down POE?

I said I had a network server that maintained the links to it's
connections, and vise versa. I didn't say it was easy. It was very
hard to get right. The problem is that I can be in a connection and
need to change my read/write status. Unfortunately, because of the
linking, I can't do that, the server would get out of sink. So what
should be simple is painful. I call into the server and have it change
my read/write status, so both objects stay in sink.

Also remember that creating all these circular links will defeat Perl's
garbage collection system, forcing you to manage your own cleanups. I
know others have warned you about this in the past.

I know I'm a broken record, but the reason I keep stressing these
points is simple: I don't believe you need to do this to yourself. If
you keep focused on the top down view and keep your interactions going
through Trainset, I truly believe you can spare yourself this pain.
I'm just trying to provide the best tips I know how, given the
information I have.

The choice is, of course, yours.

If you're going to tie all these things together like that though and
keep track of everything, I think you should take Wiggin's advice and
go with POE. It's a road tested solution designed to help you solve
this problem and you're going to have a learning curve either way you
go. Might as well spend your study time gaining skill with a good
system that will help you do this and more.

Okay, I'm going to shut up about this now. I am glad you're making
progress with your code and I wish you the best of luck, with any
implementation you choose.

James

[Gary Stainburn]

On Thursday 12 Feb 2004 4:19 pm, James Edward Gray II wrote:

> On Feb 12, 2004, at 9:21 AM, Gary Stainburn wrote:

> > I can understand the point that James made, in that the update of the
> > Trainset
> > objects is being made by a Tk event trigger, and could therefore simply
> > update the screen at the same time, e.g. clicking on a lever throws a
> > signal
> > *and* updates the screen. The problem is that it's not allways
> > possible to
> > know every object that gets affected - the state of the signal may
> > affect
> > other objects, such as changing a locomotives state from 'Stopped' to
> > 'Clear
> > To Proceed'. This is the reason behind needing the callback method.

>
> This shouldn't be an issue at all. Remember when we talked about the
> Trainset object being an interface to the whole underlying system?
> That's to solve exactly this problem, and many others.
>
> Trianset, at any given time, should be able to describe the entire
> setup. That's it's job. That's also why the TK widgets, should hold
> onto a link to the sucker.
>
> Here's how I envision an event happens: Event handler locates correct
> signal box to flip or train to change, however it does that, and make
> the change. Event handler calls update/refresh on the appropriate
> interface object(s), maybe the whole window. Update/refresh do their
> thing and eventually, I assume we end up in some kind of draw/paint
> method. In draw/paint we don't care about signal boxes and trains, we
> just want to do our job. We pull up our stored link to the Trainset,
> and ask it to tell us what it looks like right now. That will of
> course include whatever change we recently made to some signal box or
> train. When it tells us, we draw that.
>
> Trainset just needs to do its job, which is to worry about Trainset
> stuff, not interfaces. We let the interface objects worry about
> interfaces and how to display Trainsets, because that's their job.

The penny's dropped. I see what you're getting at. However there is a
drawback. The Tk interface of the training sim could do as you suggest and
simply repaint the entire window on a regular basis using a snapshot of
Trainset.

However, for the model railway use this is not sufficient. The interface then
needs to know about specific state changes in order to ensure that the
correct commands are issued to the controller.

>
> You're always very quick to resort to serious cross linking in your
> discussions. This will only increase your pain, remember that. Heck,
> isn't that the main reason you keep shooting down POE?

I am aware of this and have taken on board the things you've said before.
Rethinking which object performs which task will help reduce the need to loop
backs. For instance having a lever drive a gantry which drives a signal
eliminates the need for a loopback from the signal to the gantry.

This I got from your previous replies and they have greatly helped simplify my
code. However, because of the extent of inter-dependancy, I don't think I
can get away without them alltogether.

>
> I said I had a network server that maintained the links to it's
> connections, and vise versa. I didn't say it was easy. It was very
> hard to get right. The problem is that I can be in a connection and
> need to change my read/write status. Unfortunately, because of the
> linking, I can't do that, the server would get out of sink. So what
> should be simple is painful. I call into the server and have it change
> my read/write status, so both objects stay in sink.

This is pretty much what I had in mind. I.e. the gantry (connection) would
simply tell the Trainset (server) ' I've changed, deal with it', and the
Trainset would.

>
> Also remember that creating all these circular links will defeat Perl's
> garbage collection system, forcing you to manage your own cleanups. I
> know others have warned you about this in the past.

This if you remember was why I started my first RFC thread. Again, thanks to
your replies and those of others on the list I hope to try to avoid this as
much as possible.

>
> I know I'm a broken record, but the reason I keep stressing these
> points is simple: I don't believe you need to do this to yourself. If
> you keep focused on the top down view and keep your interactions going
> through Trainset, I truly believe you can spare yourself this pain.
> I'm just trying to provide the best tips I know how, given the
> information I have.

Agreed, and slowly I'm getting there.

>
> The choice is, of course, yours.
>
> If you're going to tie all these things together like that though and
> keep track of everything, I think you should take Wiggin's advice and
> go with POE. It's a road tested solution designed to help you solve
> this problem and you're going to have a learning curve either way you
> go. Might as well spend your study time gaining skill with a good
> system that will help you do this and more.
>

After Wiggin's and your responses today, I think I'll have to revisit POE and
see what it does. I had hoped not to to maintain simplicity of code and
deployment, but I think I may end up needing it once I get to more that one
input source so I may as well do it now.

> Okay, I'm going to shut up about this now. I am glad you're making
> progress with your code and I wish you the best of luck, with any
> implementation you choose.
>
> James

Once again, thanks for your thoughts.

Gary
--
Gary Stainburn

This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000

[James Edward Gray II]

On Feb 12, 2004, at 11:25 AM, Gary Stainburn wrote:

> I am aware of this and have taken on board the things you've said
> before.
> Rethinking which object performs which task will help reduce the need
> to loop
> backs. For instance having a lever drive a gantry which drives a
> signal
> eliminates the need for a loopback from the signal to the gantry.
>
> This I got from your previous replies and they have greatly helped
> simplify my
> code. However, because of the extent of inter-dependancy, I don't
> think I
> can get away without them alltogether.

I bet your Trainset code is pretty involved, but I think we provide
even better information when we're fixing code. Perhaps when it's at a
mostly functional level, and well documented, you could put it online
somewhere and post a link here for the curious. We might be able to
provide some good insights that way. Just a thought.

James

[Wiggins D Anconia]

> On Thursday 12 Feb 2004 4:19 pm, James Edward Gray II wrote:

> > On Feb 12, 2004, at 9:21 AM, Gary Stainburn wrote:

<snip lots of stuff>

>

> >
> > The choice is, of course, yours.
> >
> > If you're going to tie all these things together like that though and
> > keep track of everything, I think you should take Wiggin's advice and
> > go with POE. It's a road tested solution designed to help you solve
> > this problem and you're going to have a learning curve either way you
> > go. Might as well spend your study time gaining skill with a good
> > system that will help you do this and more.
> >

>
> After Wiggin's and your responses today, I think I'll have to revisit

POE and

> see what it does. I had hoped not to to maintain simplicity of code and
> deployment, but I think I may end up needing it once I get to more

that one

> input source so I may as well do it now.
>

The simplicity of the code is going to be an interesting comparison,
originally your code thoughts were very simple, but as you wander
further down the path of the implementation you are seeing how little of
the whole thing you could see at the beginning and how complicated it
*could* get. I will still hedge on the fact that once you grasp POE
that the code you have will become so incredibly simple that you will
ask yourself if it could possibly be right, because it *should* be
harder. I only say that because I have had one of these epiphanies
(sp?) before. I wrote a ton of code to handle multiple forked processes
and event queues, and after spending some time with POE threw it all out
and accomplished the same thing in a couple hundred lines, naturally
much to my dismay :-). You are right POE is a big dependency and one
that will have to be solved to distribute the app, but I also think that
the amount of time you can save implementing the whole thing by using it
would more than provide time to test and document the installation of
your app on multiple systems.

I also think that the amount you have learned about objects and message
passing in the interim will make POE much easier for you to pick up. POE
can be daunting if you have to learn POE *and* OOP at the same time, but
I think you have enough OOP background to now only need to learn POE
itself. Realize that POE itself is expansive, but you need only
concentrate on a tiny fraction of what it can offer to get all of your
parts talking. Don't worry about any of the TCP stuff, or the chat
stuff (other than the examples), I would suggest concentrating on
POE::Session, and would also suggest scrapping the notion of stand-alone
sessions. Use the POE object based sessions (you already have your
object layout pretty well set).

If you get stuck with POE ask questions! (which I know you are good at
;-)). Either here, [email]poe@perl.org[/email] or to me directly, I find this
interesting enough that I would be certainly willing to provide POE
advice. If I find some time this weekend I will boil down an example
POE object I use in a successful production app and put it online. I
have been meaning to for a while anyways, and it may give you enough of
a start to see how to convert your current object scheme easily.

But remember, just because I speak with such belief does not mean you
are not headed in the right direction without POE, only you truly know
that....

Good luck,

[url]http://danconia.org[/url]