WebFrame - (void)loadData:(NSData *)data MIMEType:(NSString *)MIMEType textEncodingName:(NSString *)encodingName baseURL:(NSURL *)URL should support integer encodingName constants

[Robert Burns]

For better consistency with Cocoa, this method (and perhaps others) should be supplemented with a method like:
- (void)loadData:(NSData *)data MIMEType:(NSString *)MIMEType textEncodingName:(int)encodingConstant baseURL:(NSURL *)URL

This would provid better consistency with Cocoa's approach where developers will expect an int there rather than an NSString. Also to clarify this method, the header explanation preceding the method should be changed to the following:

    @method loadData:MIMEType:textEncodingName:baseURL:
    @param data The data to use for the main page of the document.
    @param MIMEType The MIME type of the data.
    @param encodingName The text encoding name of the data as a string
         (not an integer contant as in cocoa method).
    @param URL The base URL to apply to relative URLs within the

[Alexey Proskuryakov]

Usually, you can convert the constant with something like:

NSString *encodingName = (NSString *)CFStringConvertEncodingToIANACharSetName(CFStringConvertNSStringEncodingToEncoding(encodingConstant)).

Given this one-line workaround, I suppose the consistency requirement might not warrant adding another nearly identical API.

If you disagree, I think it would be more effective to file a Radar (http://bugreport.apple.com) instead of a Bugzilla bug, because changes to Apple APIs involve some sort of an internal process. Closing as INVALID for this reason.

[David Kilzer (:ddkilzer)]

(In reply to comment #1)
> If you disagree, I think it would be more effective to file a Radar
> (http://bugreport.apple.com) instead of a Bugzilla bug, because changes to
> Apple APIs involve some sort of an internal process. Closing as INVALID for
> this reason.

If you're not an ADC member, you may create a free "online" ADC account at <http://connect.apple.com/> to file a bug report on that web site.

[Robert Burns]

Regarding adding bug radar, I want to understand this correctly. My sense was that WebKit does not follow the current Cocoa API in using an NSString name for the encoding where Cocoa intsead uses an integer reprsented by a contstant with the sme name. This tripped me up and I would imagine would trip up other developers. So I was suggesting changing the WebKit API to match the Cocoa API. Are you suggesting it would be better to go the other way around. Incidentally, I think the existing method could be left there for legacy reasons, but adding a method that matched the Cocoa API would reduce confusion. just reopenning to get clarification.

[Alexey Proskuryakov]

(In reply to comment #3)
> So I was suggesting changing the WebKit API to match the Cocoa API.
> Are you suggesting it would be better to go the other way around.

Certainly not! What I'm saying is that even WebKit Objective-C APIs are determined internally by Apple, so adding a new one is best requested via Radar. Since this is purely a matter of judgement (it's clear to me that your proposal is better for consistency, but Apple would need need to decide if this outweighs the problems associated with supporting multiple variants), there is probably no use in discussing this in Bugzilla.

[Robert Burns]

Added to https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa  as radar: 4995273