Agreed, I just wanted to make make a point WRT 1.4 vs <= 1.4. Now, for 1.2.2 vs. 1.3.1, that's a different story. It would be interesting to pool the various lists for the LCD JRE.
Gary > -----Original Message----- > From: Tim O'Brien [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 09, 2003 21:06 > To: Jakarta Commons Developers List > Subject: RE: [codec] Streamable Codec Framework > > Well, not so fast, I thought that the general Jakarta Commons rule was > 1.2 compatibility. > > The reasoning here is that, if some unfortunate programmer is stuck > working on some legacy code, they shouldn't need to upgrade to > JDK1.4.2_02 to get a Base64 encoding. > > But, let's discuss. > > > > On Sun, 2003-11-09 at 22:01, Gary Gregory wrote: > > > If JDK1.4 is considered a sufficient base, I could > > > > I think tha considering 1.3.1 as the base requirement is safe. > > Unfortunately, as discussed on this list under various heading, making > 1.4 a > > requirement is too aggressive. > > > > Gary > > > > > -----Original Message----- > > > From: Brett Henderson [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, November 09, 2003 19:26 > > > To: 'Jakarta Commons Developers List' > > > Subject: RE: [codec] Streamable Codec Framework > > > > > > I think the design of the codec framework could cover > > > your requirements but it will require more functionality > > > than it currently has. > > > > > > > > > > Some of the goals I was working towards were: > > > > > > > 1. No memory allocation during streaming. This eliminates > > > > > > > garbage collection during large conversions. > > > > > > Cool. I got large conversions... I'm already at > > > > > > mediumblob in mysql , and it goes up/down XML > > > > > stream > > > > > > :) > > > > > > > > > > I have a lot to learn here. While I have some > > > > > knowledge > > > > > of XML (like every other developer on the planet), I > > > > > have never used it for large data sets or used SAX > > > > > parsing. > > > > > Sounds like a good test to find holes in the design > > > > > :-) > > > > > > > > It's easy. You got callback, where you can gobble up > > > > string buffers with incoming chars for element > > > > contents. ( and there is a lot of this stuff... ) > > > > After tag is closed, you have all the chars in a big > > > > string buffer, and get another callback - in this > > > > callback you have to convert data, and do whatever > > > > necessary ( in my case, create input stream, and pass > > > > it to database ) > > > > > > This could be tricky, it's something I've been thinking > > > about but would like feedback from others about the best > > > way of going about it. > > > > > > The data you have available is in character format. > > > The base64 codec engine operates on byte buffers. > > > The writer you want to write to requires the data > > > to be in character format. > > > > > > I have concentrated on byte processing for now because > > > it is the most common requirement. XML processing > > > requires that characters be used instead. > > > > > > It makes no sense to perform base64 conversion on > > > character arrays directly because base64 is only 8-bit > > > aware (you could split each character into two bytes > > > but this would blow out the result buffer size where > > > chars only contain ASCII data). > > > > > > I think it makes more sense to perform character to > > > byte conversion separately (perhaps through > > > extensions to existing framework) and then perform > > > base64 encoding on the result. I guess this is a > > > UTF-16 to UTF-8 conversion ... > > > > > > What support is there within the JDK for performing > > > character to byte conversion? > > > JDK1.4 has the java.nio.charset package but I can't > > > see an equivalent for JDK1.3 and lower, they seem to > > > use com.sun classes internally when charset conversion > > > is required. > > > > > > If JDK1.4 is considered a sufficient base, I could > > > extend the current framework to provide conversion > > > engines that translate from one data representation > > > to another. I could then create a new CodecEngine > > > interface to handle character buffers (eg. > > > CodecEngineChar). > > > > > > > > > > > > > 3. Customisable receivers. All codecs utilise > > > > > > > receivers to > > > > > > > handle conversion results. This allows > > > > > different > > > > > > > outputs such as > > > > > > > streams, in-memory buffers, etc to be supported. > > > > > > > > > > > > And writers :) Velocity directives use them. > > > > > > > > > > Do you mean java.io.Writer? If so I haven't > > > > > included > > > > > direct support for them because I focused on raw > > > > > byte > > > > > streams. However it shouldn't be hard to add a > > > > > receiver to write to java.io.Writer instances. > > > > > > > > > > > > My scenarios: > > > > - I'm exporting information as base64 to XML with help > > > > ov velocity. I do it through custom directive - > > > > in this directive I get a Writer from velocity, where > > > > I have to put my data. > > > > > > > > Ideally codec would do: read input stream - encode - > > > > put it into writer without allocating too much > > > > memory. > > > > > > > > I'm importing information: > > > > - I have stream ( string ) of base 64 data - > > > > codec gives me an input stream which is fed from this > > > > source and does not allocate too much memory and > > > > behaves polite... > > > > > > > The current framework doesn't handle direct conversion > > > from an input stream to an output stream but this > > > would be simple to add if required. > > > Again, the hard part would be the char/byte issues. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > ----------------------------------------------------- > Tim O'Brien - [EMAIL PROTECTED] - (847) 863-7045 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
