commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (O'brien, Tim)
Subject RE: [codec] RE:
Date Tue, 04 Feb 2003 18:38:40 GMT

I think the only blocker to HttpClient using your Base64 class as is, is the
chunking.  I do agree that setting flags on an instance of Baset64 is
preferable to adding a flag in a method signature - but I think that adding
a flag to a method signature would provide get us to a short-term goal and
allow for more immediate reuse.    

To this end, I drew up a plan for Base64 -

I'm trying to set very small defined and attainable goals for a 1.1 release
which will include Base64 to be shared across XML-RPC and HttpClient.  There
are a lot of good discussions, but I think that "step2" would at least get
us to a point of release.

Tim O'Brien 

> -----Original Message-----
> From: Martin Redington [] 
> Sent: Tuesday, February 04, 2003 12:24 PM
> To:
> Cc: 'Jeffrey Dever'; commons-dev; rhoegg
> Subject: Re: [codec] RE:
> Hi all,
>      personally I favour Ryan's suggestion of setting flags (and/or 
> system properties) separately to obtain non-RFC compliant 
> behaviour (or 
> to specify which RFC to follow, where they conflict), or to specify 
> that exceptions should be raised when encountering a non-Base64 char, 
> rather than adding additional args to method signatures.
> Given the wide usage of this code, and the need to inter-operate 
> smoothly with other implementations that may or may not comply with a 
> particular RFC, giving the end-user as much flexibility as 
> possible is 
> probably a good thing and shouldn't add too much complexity to the 
> code. Maybe both approaches would be appropriate.
>     cheers,
>            m.
> >

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message