Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Remote EFS designs

On Thu, May 28, 2009 at 9:31 PM, Andrew Gvozdev <> wrote:
> Hi James,
> IPath <==> URI conversions are not always properly handled

I really hope that the remote EFS representation doesn't screw the
pooch in the same way that IPath does. IPath validates the
representation of the format based on the current operating system's
conventions rather than what the remote file system will believe in.
For example, it's impossible to have an IPath with a : in it, despite
the fact that (a) it's a perfectly valid character on other operating
systems and (b) it's a perfectly valid character to have in e.g. a
database-backed filing system.

The other aspect of resources is that Eclipse (as an IDE) has mainly
broken the concept of file encodings. Everything tends to use randomly
whatever the client's OS has as its default encoding, which causes
problems when moving between (a) operating systems, and (b) locales.
On the other hand, UTF-8 is a de-facto standard (and was at the time
Eclipse was created) and realistically is the only sensible default
for resources. This is especially the case when a distributed resource
system is at play (i.e. the client may be on a completely different
OS/Locale than the server)

Note that this is explicitly *not* the same as 'pretend
file.encoding=utf8'. The default *should* be utf-8, but file.encoding
*should* still refer to the local OS (so that if there are files which
need to be read in the system encoding, e.g. MacRoman, it's still
possible to do so).  Making the default UTF-8 would mean complete
transparency whilst still permitting a case-by-case override to the
local OS encoding (which is more important on e.g. EBCDIC or other
archaic non-ASCII character sets)

Sadly, my faith in either of these two problems being solved - either
for e4 or any future version of Eclipse - is basically grounded in



Back to the top