On Sep 29, 2009, at 11:27 AM, Krzysztof Kosiński wrote:
We can, and in fact we must in order to support editing directly on
network shares (GIO). The convention used by absolutely everyone is to
use the file:/// scheme for local files.
No...
There are many things that are *close*
We want 100%, not 95%
So for our internals we must use something that is consistent and also covers 100% of the use cases we need. As we touch each API, we can either feed something in directly (as I mentioned, both Mental and I have researched this URI/IRI issue) or we can do a quick conversion per API.
Also... at runtime we might need to track some additional data. Bob mentioned some additions to URI classes that people do in order to make things work. That is what we need to do. However, instead of having redundant code all over the place doing potentially buggy conversions, we need to have a consistent class that we use internally.
To quote RFC 3987 "which means that IRIs can be used instead of URIs,
where appropriate, to identify resources." Later on it also mentions "Every URI is by definition an IRI."
You also seem to not be grasping what I'm trying to convey. Let me try to clarify:
* URI's *can* be used for all sorts of things, but as is the standard library calls for conversions *fail* in our use cases.
* There are many ways to tweak data in and out of URI's to make them more useful
* RFC 3987 codifies the best practices of "useable URIs" and calls them "IRIs"
* We need to use IRIs internally
* We need to use a class that is more than just a bare string
* We should use them to reference files