[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MD5
From: |
Richard Frith-Macdonald |
Subject: |
Re: MD5 |
Date: |
Thu, 23 Jan 2003 12:03:02 +0000 |
On Thursday, January 23, 2003, at 11:44 am, David Ayers wrote:
Thanks Pete,
I don't think the issue right now is "how" to implement it (because
with yours we now seem to have three implementations) but rather
"where". But let me get back to "how" anyway. I think the following
API would be usefull
@interface NSData (MD5)
- (NSData *)md5Digest; /* This method actually implements the
calculations*/
- (NSString *)md5StringUsingEncoding: (NSStringEncoding) enc;
- (NSString *)md5String; /* uses default encoding.*/
@end
@interface NSString (MD5)
- (NSString *)md5StringUsingEncoding: (NSStringEncoding) enc;
- (NSString *)md5String; /* uses default encoding.*/
@end
But more importantly is where these Categories should go:
I already added a simple category of NSData to the Additions library,
consisting only of an -MD5Digest method returning an NSData object.
I'm not sure what the other methods are supposed to do exactly ... the
string encoding makes sense where the string is the input to the digest
... but what to do when producing string output? I don't think there
is any standard format for representing a digest as a string, unless
it's to encode the bytes as pairs of hex digits.
certainly, you can't just use [NSString-initWithData:encoding:] to
produce a string as you have no guarantee that the bytes of the digest
are valid characters in the encoding you specify.
1. base/Additions
Obviously I think that's a good place :-)
2. gscrypt - well actually I wouldn't change the existing
implementation, I would just try handling the pam_-problem
transparently with LIBRARY_DEPENDS_UPON or/and configure.
Yep.
3. some official gnustep-base-extension library to catch alle
GNUstep-base features that base doesn't depend upon and could be
written to compile agains OS X/4.2.
That's really what I want the Additions library to be ... the idea was
that stuff in this library would *automatically* be available with the
base library (though be clearly separate), and also be usable on
systems where the Base library itsself was not used.
- Re: [GSWHackers] [PATCH/RFC] GSWeb - single GSW/WO namespace frameworks, (continued)
- Re: [GSWHackers] [PATCH/RFC] GSWeb - single GSW/WO namespace frameworks, David Ayers, 2003/01/22
- Re[2]: [GSWHackers] [PATCH/RFC] GSWeb - single GSW/WO namespace frameworks, Manuel Guesdon, 2003/01/22
- Re: [GSWHackers] [PATCH/RFC] GSWeb - single GSW/WO namespace frameworks, David Ayers, 2003/01/22
- Re[2]: [GSWHackers] [PATCH/RFC] GSWeb - single GSW/WO namespace frameworks, Manuel Guesdon, 2003/01/22
- Re: [GSWHackers] [PATCH/RFC] GSWeb - single GSW/WO namespace frameworks, David Ayers, 2003/01/22
- Re[2]: [GSWHackers] [PATCH/RFC] GSWeb - single GSW/WO namespace frameworks, Manuel Guesdon, 2003/01/22
- MD5, David Ayers, 2003/01/22
- Re: MD5, Pete French, 2003/01/23
- Re: MD5, David Ayers, 2003/01/23
- Re: MD5, Pete French, 2003/01/23
- Re: MD5,
Richard Frith-Macdonald <=
- Re: MD5, David Ayers, 2003/01/23
- Re[2]: MD5, Manuel Guesdon, 2003/01/24
- Re: MD5, David Ayers, 2003/01/24
- Re: MD5, Richard Frith-Macdonald, 2003/01/24
- Re: MD5, David Ayers, 2003/01/24
- Re: MD5, David Ayers, 2003/01/24
- Re[2]: MD5, Manuel Guesdon, 2003/01/25