Bug 283033 - [api] remoteFileTypes extension point should include "xml" type
Summary: [api] remoteFileTypes extension point should include "xml" type
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.2 M6   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on: 304170
Blocks:
  Show dependency tree
 
Reported: 2009-07-09 10:55 EDT by David McKnight CLA
Modified: 2010-03-15 17:04 EDT (History)
0 users

See Also:


Attachments
patch with changes for xml file type enhancement (39.74 KB, patch)
2009-07-09 13:49 EDT, David McKnight CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David McKnight CLA 2009-07-09 10:55:16 EDT
As per bug 189353, xml file types need to be treated differently from files that are considered "binary" or "text".  For known XML file types, RSE, always downloads as binary and then determines encoding via inspection of the text.  However there are some file types (for example WSDL and XSD) that are XML yet RSE is not aware of that and therefore is unable to treat appropriately unless there's a means to indicating that.  I think the best way to resolve this is to use the remoteFileTypes extension point to include an "xml" file type.
Comment 1 David McKnight CLA 2009-07-09 13:49:42 EDT
Created attachment 141223 [details]
patch with changes for xml file type enhancement

Here is a patch to show the code changes needed. Due to the api changes, I'm not sure which version this could go into - so I've left out the @since tags and left the manifest files unchanged.
Comment 2 Martin Oberhuber CLA 2010-02-28 18:18:23 EST
Technically, the changes to ISystemFileTypes are API breaking, because you are adding methods to an interface and the interface is not marked @noimplement.

From my reading of the source, though, it looks like nobody could ever meaningfully implement ISystemFileTypes, so not marking the interface @noimplement was probably an oversight. I filed bug 304170 for discussing this and tracking it. If I am right, then please have bug 304170 fixed -- then the version number may remain at 3.2 and the @since tags may remain as they are now.
Comment 3 David McKnight CLA 2010-03-10 12:30:45 EST
I've committed the changes to cvs.