Re: Random String Generator

[Ralph Daugherty <rdjfc@xxxxxxxxxxxxx>]

   No doubt, the enterprise solution is to put the jars in the 
classpath and use your provided override code of the HTTPStreamResponse 
and get on quickly to a variety of method call sequences to create 
CAPTCHA's and have WDSc prototype the calls for RPG.

   I have many plans for this code so was a personal effort. I want to 
have a standalone jar for my uses so was worth the one time effort. The 
code has been around awhile and is pretty stable. Still, no reason for 
an enterprise to unnecessarily fork and have potential code updates.

   If a little more flexibility is required with modeifications, then I 
have a base to do that. We have the bases covered.

   I have some testing to do to see what happens anyway. :)

 rd


Thorbjørn Ravn Andersen wrote:
> Ralph Daugherty skrev:
> >     The OP, Dave I think, and others may be interested in doing this I 
> > hope. I have completed isolating the Batik PNG classes and won't be 
> > using any supporting jars.
> >
> >   
> Great.  Quite a bit of work there, indeed.
>
> There is one more thing you might want to take into consideration, 
> namely that you have basically forked the batik PNG libraries, and you 
> will have to do this work again when a new release of Batik comes out, 
> if you want to use the latest version of the library.  Depending on your 
> needs this might be a good or a bad thing :)
>
> There is as such no technical reason other than space considerations to 
> pull classes out of jars.
>
> >     Looking forward to hearing that someone is getting a CAPTCHA from 
> > this on the iseries.
> >
> >   
> Me too.  The more code the better.