> 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 PROTECTED] 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, http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
