Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: tobrien@transolutions.net (O'brien, Tim)
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Cc: "'Jeffrey Dever'" <jsdever@sympatico.ca>,
	"'rhoegg'" <rhoegg@isisnetworks.net>
Subject: RE: [codec] RE: Base64.java
Date: Tue, 4 Feb 2003 13:04:47 -0600
Message-ID: <008f01c2cc80$4c7bfef0$7629f80c@tobrien>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.33.0302041354290.28137-100000@umbongo.flamefew.net>
Importance: Normal

You example below would make sense if the Base64 implementations were
dramatically different.  It should be noted that the only sticking point is
chunked encoding - in essence, XML-RPC needs an implementation that adds
"\n" every 76 characters, and HttpClient does not.  Making two different
implementation classes in this case might be overkill.

--------
Tim O'Brien

> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com] 
> Sent: Tuesday, February 04, 2003 12:56 PM
> To: Jakarta Commons Developers List
> Cc: tobrien@transolutions.net; 'Jeffrey Dever'; rhoegg
> Subject: Re: [codec] RE: Base64.java
> 
> 
> 
> The concept of setting flags etc seems to be quite poor OO. 
> Maybe I'm not understanding things properly though.
> 
> Shouldn't it be a classic FactoryMethod pattern?
> 
> Base64Utils
> Base64 interface
> 
> hidden classes:
> 
> RFCBase64
> OtherBase64
> JimsBase64
> 
> and then:
> 
> 
> Base64Utils->
> 
> public static Base64 RFCBase64 = new RFCBase64().
> ...etc..
> 
> ??
> 
> Hen
> 
> 
> On Tue, 4 Feb 2003, Martin Redington wrote:
> 
> >
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org