[Top][All Lists]

[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.*/

@interface NSString (MD5)
- (NSString *)md5StringUsingEncoding: (NSStringEncoding) enc;
- (NSString *)md5String; /* uses default encoding.*/

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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]