Re: [platform-core-dev] file encoding proposal

[Rafael Chaves <Rafael_Chaves@xxxxxxxxxx>]

Bob, I know it has been a long time since your post, but I hope you still
have the context to answer two questions I have:

Re: 1) why do you think we need to allow URIs instead of file paths?

Re: 2) why should the file path / URI be passed to the content interpreter?
Content interpreters are intended to be format-specific... they should not
care about anything else than content.

I guess it would be just fair if I answered your questions below:

Re: 3) content interpreters are provided by the plugin contributing content
types
(http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/content_types.html).
 Runtime will provide two content types: text and xml. JDT will provide
java properties. PDE will provide plugin manifest. Ant will provide build
script. So, the idea is that we will only provide content types for things
that we are the "official" representatives, with the exception of text and
xml, which will be provided by us because they play a fundamental role in
Eclipse, and letting 3rd party plugins to compete on who ought to define
them would just increase the chances for conflicts and incompatibilities.

Re: 4) The UI for encoding is in place since last week's integration build
- check the property dialog for resources. You can set a
project/folder/file encoding with it.

Re: 5) We are adding a method that takes a reader as opposed to a input
stream.

Re: 6) We don't ensure charsets are valid, neither we offer any protection
in that area. A invalid charset for one user may be valid for another.
Clients may try to default to another charset if the one we provide fails,
but we will not be doing that under the covers.

Re: 7) file-specific encoding is currently being used throughout Eclipse

Rafael

February 23, 2004 2:35 PM
To: platform-core-dev@xxxxxxxxxxx
cc:
From: Bob Foster <bob@xxxxxxxxxx>
Subject: Re: [platform-core-dev] file encoding proposal



1. Just because you don't see the need for a per-file encoding attribute
doesn't mean you should make it impossible an IContentInterpreter to
have one (or other levels of granularity). The fileEncoding parameter
should be changed in name and semantics to "String uri". (Not a "file
path" or you'll be committing another kind of sin.)

2. The extension (which should be a URI) doesn't seem to be passed to an
IContentInterpreter. ???

3. How does a plugin or user override the platform-provided
"implementations of IContentInterpreters for xml and other popular file
formats"? Not that we don't trust you, but we don't want to exchange one
hard-coded scheme for another.

4. The UI Changes section seems to allude to features not described
elsewhere in the document. Project encoding? What does it mean? The
paragraph identified (5) below makes me very nervous.

5. The third "scenario" is not a use case. It is an inconclusive note
about how to set encodings for newly created files. Several sentences in
this paragraph are either incorrect or worrying. a. Every file (not just
a new file) should get an encoding from an IContentInterpreter in the
process of being saved. But you have boxed yourself in by allowing only
inputstreams to be considered. For output, you need a method that
accepts a Reader. b. All *.xml files do NOT have a UTF-8 encoding. They
should always have the encoding in the xml/encoding declaration, if one
is present.

6. You do not specify error handling for cases when the encoding used
for input or output is detected to be wrong or insufficient. The user
should at least be warned.

7. Where is this stuff actually used? I checked the obvious
documentprovider classes in M7 and didn't see it.

Bob

Rafael Chaves wrote:
> A new revision of the improved file encoding proposal has been made
> available off the Platform/Core web page:
>
>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/dev.html#plan_current
>
>
> Comments are welcome and should be made on the Platform/Core development
> list (platform-core-dev@xxxxxxxxxxx) or the corresponding Bugzilla PR
> (#37933).
>
> Thanks,
>
> Rafael


_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
 http://dev.eclipse.org/mailman/listinfo/platform-core-dev