On 9/22/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > > > > robert burrell donkin-2 wrote: > > > > your patch would require double buffering when used with direct > > buffers and would require convertion of structured data into bytes. > > so, it's unsatisfactory for use cases 1 and 2. however, i'm not sure > > whether this is something that is worthwhile arguing about. > > > > You haven't even see the patch, so how do you know?
this is the problem with lots of small patches: i don't understand where you are taking the design > Double buffering: I don't see why. The patch was designed to work with the > buffers provided by a thread that's doing select(). it's direct use of byte arrays which worried me. how do you propose to handle memory mapped files without double buffering? > Convertion of structured data into bytes: How's that different from what we > have now? And, if you really want to provide structured data, then the > proper way to do so is to refactor an interface out of the MimeTokenStream > and provide an implementation that produces the same events. Or, do the same > thing by firing events to a ContentHandler. the design question is at what level this interface should be. the API would be better if MimeTokenStream were an interface and i'm satisfied that this design can satisfy the structured data use case. can anyone else see any problems with this approach? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
