You could make use of Filter::Stackable to put in a "sieve" filter in front of Filter::Reference. Your sieve could then check to make sure (read: hand waving) the data it gets from whatever is valid for Filter::Reference. If it isn't just eat it. Depending on what Filter::Reference uses for serialization (Storable? YAML?) you can do a check on the first few bytes to see if it is valid.
I don't have an example off the top of my head to show you or further explain the concept, but I do know that in the .NET remoting architecture, their Sink concept loosely follows the Filter::Stackable concept. And there are a bit more hits on google for custom remoting sinks (to do things like trap errors before they get too far up the chain). HTH On 5/31/07, Zach Roberts <[EMAIL PROTECTED]> wrote:
Hello POE, I have a situation which I am sure is not unique, but I haven't been able to find much information about it. I am using POE to provide a parent process which spawns many children (via POE::Wheel::Run) who do their various things (in my case some memory heavy conversion and manipulation of database records). This is working beautifully and has made my life very simple and happy. There is one nuisance that I haven't been able to figure out though, and I am hoping that someone can help. I am using POE::Filter::Reference to handle the the child to parent communication of the results from each child process. I am currently using a POE::Filter::Reference as the StdoutFilter parameter to my POE::Wheel::Run, similar to the examples in the POE Cookbook (see http://poe.perl.org/?POE_Cookbook/Child_Processes_3). This works really, really well for cases where all of the code knows that it is POE code, and that anything the child process writes to STDOUT is going back to the parent process through the filter. What should I do though for the cases where the child process (or more likely one of the modules it uses) may have no idea that it is POE code and that STDOUT should be reserved for communication back to the parent? One case, as an example, is when a --verbose flag is passed to the child process resulting in all kinds of chatter on STDOUT that the filter is not good at ignoring as non POE communication. Is there some filehandle trickery that can be done to convince all the non-POE STDOUT printing to go elsewhere, like STDERR, and then only the POE specific printing can monopolize STDOUT for filter printing only? Is there a way of chaining filters together to ignore non POE communication on STDOUT? Any other ideas (short of the obvious make all the other code running in the child behave the way I want it to)? If this is unclear, feel free to say so and I will work on a self contained program to post as an example. Thanks again, Zach Roberts
