Sure. Something "flyweight" or "inside-out" would work. All manner
of thing could be stored within that inside-out thing. The blessed
envelope's class should probably provide members to get at the inside-
out contents, however. It seems messy to assume everybody knows what
the contents l
> This way you could
> maintain important info from the beginning of the stack all the way to
> end of the stack. Filters that are aware of the envelope can use it,
> otherwise, it is just another arrayref with records.
cant it just be a blessed arrayref blessed to a singleton class that
has a sing
I think this is a very sane approach. My only comment would be to make
the Datatype class named to something else, such as what it really is:
Envelope. Then the Envelope itself can contain properties such as if
it contains an error or whatever. How we do dynamic properties
without affecting the co
Yay, my outbound e-mail works again! I can comment on this thread now!
I require three things (today... maybe more, or others tomorrow):
1. Maintain backwards compatibility. Old and new filters should
interoperate. Require the least amount of collateral code change
possible. Most of the
The only reason I questioned it is because I heard mentioned in #poe
about wanting to maintain the non-POE-ness of filters (ie. usage
outside of POE). I could have the context wrong, though and I forgot
specifically who said it? Chris maybe?
On 8/15/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
> Ho
How is adding that error mechanism binding the filter to the wheel any
more than the current get_one() and put() API is?
I don't care how many API's we have to break, Filters should have
proper error checking.
Sure there are alot of third party filters, but 90% of the devs are on
#poe, and the oth
This certainly looks promising, but how do you know when to read it?
When the filter returns an empty array ref? I'd like not for the error
checking to be required after every time an empty array ref gets
returned, because that could be quite a few times depending on how big
of a buffer the filter
My work on POE::Filter::SSL is relevant here.
I needed a way to pass OOB data back to the readwrite wheel during the SSL
negotiation. The method LotR and I came up works great. I pass an array
ref to get_one (lets call it $oob), and any time a filter has OOB data, it
blesses it into a namespace,
There was a discussion about this on #poe, which I thought I'd share:
<+nperez> an isa check every single time something goes through the
filter just seems like overkill...
<+LotR> compared to the work that Filter::XML does?
<+nperez> yes, because it will add up. hold on, writing a benc
I second this method. It provides a simple API, and simple Filters
wouldn't have to be modified much.
On 8/14/07, Nicholas Perez <[EMAIL PROTECTED]> wrote:
> I second this.
>
> And I think something like POE::Filter::Error would be a good place to
> encapsulate something like that. But like what
On Tue, 2007-08-14 at 12:00 -0500, Nicholas Perez wrote:
> I second this.
>
> And I think something like POE::Filter::Error would be a good place to
> encapsulate something like that. But like what was stated in IRC,
> making the error appear in the normal data stream could be
> problematic. I sug
I second this.
And I think something like POE::Filter::Error would be a good place to
encapsulate something like that. But like what was stated in IRC,
making the error appear in the normal data stream could be
problematic. I suggest a property on the filter itself store an error
object that can b
Hi,
so with filters becoming more and more complex (e.g. POE::Filter::XML,
Filter::HTTPD) I think it would be a good idea to have a standard way of
reporting back errors.
Currently Filter::HTTPD returns a HTTP::Response object instead of a
HTTP::Request, to send back to the remote end. Filter::XM
13 matches
Mail list logo
