On Wed, May 05, 2004 at 01:31:36PM -0400, Ben Kennedy wrote: > > "Rocco Caputo" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Dylan Hardison asked on IRC whether it was possible to limit the > > length of an input line using POE::Filter::Line. I admitted that it's > > not currently an option but could become one. > > > > We put down some ideas about what to do with long lines. Four > > possibilities came up: > > > > Ignore the excess characters on a line. Return a truncated line > > with no exception. > > > > Same as #1, but with some sort of marker signaling an exception. > > > > Discard the long line entirely. Don't return anything, and don't > > throw an exception. > > > > Same as the preceding, but with an exception marker attached. > > Using the filter as just a tool to truncate long lines seems counter to the > general goal of being a protocol abstraction layer. However, if the > protocol is in fact "lines less than N bytes", the behavior when seeing a > longer line should be the same as when POE::Filter::Reference sees a stream > of bytes it can't thaw. Ideally, I would love to see any exceptions in the > protocol be handled by the same mechanism as any error by triggering the > ErrorEvent of the wheel, or creating a new FilterError event that can be > triggered whenever a Filter class throws an exception.
The idea came up after Dylan asked what would happen if someone sent a lot of data without a newline. The answer today is: Your process would eventually run out of memory and exit. It's not a very good answer. I like the idea of throwing filter exceptions as a different event. I think it could be generalized as a basic out-of-band event. It could also report real out-of-band data, as found in STDERR and in OOB packets. Making it work would require some fundamental changes to filters. I don't think backwards compatibility can be guaranteed here, but any hypothetical breakage would be hidden behind the POE::Wheel interface. People won't notice it unless they have custom wheel, filter, or driver classes. It might be useful to consider a hypothetical POE::Wheel::SendRecv while we're discussing out-of-band data. Recv() returns a peer address on successful receipt of a packet. It's used in connectionless UDP programs, where each packet may come from a different location. It's important to associate the peer address with each packet so a program can send a response to the right place. A separate out-of-band channel doesn't help here. Is there a way to reconcile both types of meta-data? -- Rocco Caputo
