On 23 March 2013 14:27, Simone Tripodi wrote:
> Thanks a lot for the priceless effort on B64, Seb!
>
> what's the status ATM, do you think it can be included in a RC?
Yes.
> TIA, all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://t
Thanks a lot for the priceless effort on B64, Seb!
what's the status ATM, do you think it can be included in a RC?
TIA, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Mar 21, 201
On 20 March 2013 18:22, sebb wrote:
> On 20 March 2013 14:42, Gary Gregory wrote:
>> On Wed, Mar 20, 2013 at 10:25 AM, Mark Thomas wrote:
>>
>>> On 20/03/2013 01:09, sebb wrote:
>>> > I think QPD(ecode) is now OK; it handles lowercase hex and rejects
>>> > invalid characters.
>>> >
>>> > Base64D
On 20 March 2013 19:46, Gary Gregory wrote:
> Hi All:
>
> It seems to be that the B64 code needs work for 1.3 no matter what. So I am
> not sure I agree with Simo because:
> - We rework B64 for 1.3 as proposed by Sebb.
It's not really rework - just tidying up the new code so it agrees with Java 6
Hi All:
It seems to be that the B64 code needs work for 1.3 no matter what. So I am
not sure I agree with Simo because:
- We rework B64 for 1.3 as proposed by Sebb.
- We rework B64 again for 1.4 using Java 6.
It seems like asking for trouble on subtle compatibility issues from 1.2 to
1.3 and agai
My proposal is: let's go ahead with Java5 compatibility for 1.3, let's
increase for 1.6 in 1.4 or 2.0
>
> If we do not want to go with Java 6 and that method, we should
> probably treat concatenated encodings the same way it does.
> But of course we won't emulate the crash!
>
+1
My 2 cents,
-Sim
On 20 March 2013 14:42, Gary Gregory wrote:
> On Wed, Mar 20, 2013 at 10:25 AM, Mark Thomas wrote:
>
>> On 20/03/2013 01:09, sebb wrote:
>> > I think QPD(ecode) is now OK; it handles lowercase hex and rejects
>> > invalid characters.
>> >
>> > Base64Decode handles valid input OK, and rejects some
On Wed, Mar 20, 2013 at 10:25 AM, Mark Thomas wrote:
> On 20/03/2013 01:09, sebb wrote:
> > I think QPD(ecode) is now OK; it handles lowercase hex and rejects
> > invalid characters.
> >
> > Base64Decode handles valid input OK, and rejects some invalid input,
> > but could perhaps do with tweakin
On 20/03/2013 01:09, sebb wrote:
> I think QPD(ecode) is now OK; it handles lowercase hex and rejects
> invalid characters.
>
> Base64Decode handles valid input OK, and rejects some invalid input,
> but could perhaps do with tweaking to handle PAD characters better.
> At present it treats an embed
>
> As far as I know, it already behaves as per the article, except I have
> just noticed that RFC2045 requires invalid characters to be ignored.
> That should be trivial to fix now that the code has been re-organised.
>
unfortunately, after a (not deep) search, the most useful place I
found, wher
On 20 March 2013 08:26, Simone Tripodi wrote:
> priceless!!!
>
>> At present it treats an embedded PAD as the end of input (as per
>> Codec) but maybe it would be better to only allow 1 or 2 PADs at the
>> end?
>
> IMHO having such behaviour is acceptable, but if it doesn't cost you
> too much, ha
priceless!!!
> At present it treats an embedded PAD as the end of input (as per
> Codec) but maybe it would be better to only allow 1 or 2 PADs at the
> end?
IMHO having such behaviour is acceptable, but if it doesn't cost you
too much, having the behaviour described in Wikipedia[1] is a 'nice to
I think QPD(ecode) is now OK; it handles lowercase hex and rejects
invalid characters.
Base64Decode handles valid input OK, and rejects some invalid input,
but could perhaps do with tweaking to handle PAD characters better.
At present it treats an embedded PAD as the end of input (as per
Codec) bu
On 03/19/2013 03:44 PM, Simone Tripodi wrote:
> Hi all guys,
>
> is there anything you want to discuss before I go ahead with a new RC?
> I am performing some ITs in non-public projects and I planned to cut a
> new RC in 1-2 days...
>
> What about FILEUPLOAD-137?
>
> @Thomas: we didn't get any f
There's one other issue - Commons Codec does not support soft line
breaks in quoted printable decoding.
As far as I know, those are required.
On 19 March 2013 19:46, Matt Benson wrote:
> Yes, you can shade only the classes needed. Getting rid of code that does
> the same thing across multiple Co
Yes, you can shade only the classes needed. Getting rid of code that does
the same thing across multiple Commons components seems a worthwhile use of
time IMO and really shouldn't represent any more work than fixing the
broken classes in [fileupload]. Also, no triage is required to figure out
how
-1 if this results in a huge increase in size of the jar.
If shading can extract only the required classes, that might be OK,
but it seems like a lot of work when the code already works for valid
input.
I think the only outstanding problems are the way the decoders handle
invalid input.
On 19 Ma
> Why not depend on [codec] and shade, then?
+1
Maurizio Cucchiara
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 19 March 2013 18:48, Gary Gregory wrote:
> How many gigs of ram do phone that run Java have these days?
Some not a lot, see for example:
https://issues.apache.org/jira/browse/COMPRESS-221
> Gary
>
> On Mar 19, 2013, at 14:39, sebb wrote:
>
>> On 19 March 2013 18:32, Gary Gregory wrote:
>>>
Why not depend on [codec] and shade, then?
Matt
On Tue, Mar 19, 2013 at 1:48 PM, Gary Gregory wrote:
> How many gigs of ram do phone that run Java have these days?
>
> Gary
>
> On Mar 19, 2013, at 14:39, sebb wrote:
>
> > On 19 March 2013 18:32, Gary Gregory wrote:
> >> Yes, why not depend on
How many gigs of ram do phone that run Java have these days?
Gary
On Mar 19, 2013, at 14:39, sebb wrote:
> On 19 March 2013 18:32, Gary Gregory wrote:
>> Yes, why not depend on commons-codec?
>
> Codec is nearly 4 times the size of file upload.
> Not an ideal partner.
>
>> Gary
>>
>> On Mar 19
On 19 March 2013 18:32, Gary Gregory wrote:
> Yes, why not depend on commons-codec?
Codec is nearly 4 times the size of file upload.
Not an ideal partner.
> Gary
>
> On Mar 19, 2013, at 14:28, Simone Tripodi wrote:
>
>> Hi there,
>>
is there anything you want to discuss before I go ahead w
On 19 March 2013 18:27, Simone Tripodi wrote:
> Hi there,
>
>>> is there anything you want to discuss before I go ahead with a new RC?
>>> I am performing some ITs in non-public projects and I planned to cut a
>>> new RC in 1-2 days...
>>
>> I think there are still some issues in Base64Decoder (th
Yes, why not depend on commons-codec?
Gary
On Mar 19, 2013, at 14:28, Simone Tripodi wrote:
> Hi there,
>
>>> is there anything you want to discuss before I go ahead with a new RC?
>>> I am performing some ITs in non-public projects and I planned to cut a
>>> new RC in 1-2 days...
>>
>> I think
Hi there,
>> is there anything you want to discuss before I go ahead with a new RC?
>> I am performing some ITs in non-public projects and I planned to cut a
>> new RC in 1-2 days...
>
> I think there are still some issues in Base64Decoder (this time not
> ones I accidentally introduced - sorry ab
On 19 March 2013 14:44, Simone Tripodi wrote:
> Hi all guys,
>
> is there anything you want to discuss before I go ahead with a new RC?
> I am performing some ITs in non-public projects and I planned to cut a
> new RC in 1-2 days...
I think there are still some issues in Base64Decoder (this time
Hi all guys,
is there anything you want to discuss before I go ahead with a new RC?
I am performing some ITs in non-public projects and I planned to cut a
new RC in 1-2 days...
What about FILEUPLOAD-137?
@Thomas: we didn't get any feedback from Tina on FILEUPLOAD-202, did
she try to contact you
27 matches
Mail list logo
