Remove redundant txt fileswip/oholy/update-docs

"meson dist" distributes whole git snapshot including various documents,
which haven't been distributed earlier. Those texts can be found at the
following mailing list and are linked from https://wiki.gnome.org/Projects/gvfs
also:
https://mail.gnome.org/archives/gnome-vfs-list/2006-September/msg00023.html

2 files changed, 0 insertions, 567 deletions

diff --git a/txt/vfs-ideas.txt b/txt/vfs-ideas.txt
deleted file mode 100644
index 7b41a064..00000000
--- a/txt/vfs-ideas.txt
+++ /dev/null
@@ -1,425 +0,0 @@
-Subject: Plans for gnome-vfs replacement
-
-Recently there has been a lot of discussions about the platform and
-the correct stacking order and quality of the modules. Gnome-vfs
-is a clear problem in this discussion. Having spent the last 4 years
-as the gnome-vfs maintainer, and even longer as the primary gnome-vfs
-user (in Nautilus) I'm well aware of the problems it has. I think that
-we've reached a point where the problems in the gnome-vfs architecture
-and its position in the stack are now ranking as one of the most
-problematic aspects of the gnome platform, especially considering the
-enhancements and quality improvements seen in other parts of the
-platform.
-
-So, I think the time has come for a serious look at what gnome-vfs
-could be. I've spent much time last week thinking about the weaknesses
-and problems of the current gnome-vfs and possibilities inherent in a
-redesign, both having learnt from 7 years of gnome-vfs existance and
-the improvements in the platform (both Gnome and surrounding
-technologies) since 1999 when it was designed.
-
-As soon as you spend some time looking at this problem is evident that
-to solve the platform ordering issues we really need a clean cut from
-the current gnome-vfs. I think the ideal level for a VFS would be in
-glib, in a separate library similar to gthread or gobject. That way
-gtk+ would be able to integrate with it and all gnome apps would have
-access to it, but it wouldn't affect small apps that just wants to use
-the glib core. Furthermore, not being libglib lets us use GObjects in
-the vfs, which means we can make a more modern API. Of course, this
-places quite some limitations on the vfs, especially in terms of
-dependencies and how integration with a UI should work.
-
-Any thoughs on the design of a vfs to replace gnome-vfs must be based
-on a solid understanding of the problems with the current system, to
-avoid redoing old mistakes and to make sure that we solve all the
-known problems of the current system. So, I'm gonna start by
-describing what I see as the main architectural and "hard" problems in
-gnome-vfs.
-
-The first, and most often discussed problem is of course
-compatibility. The various desktops use different vfs implementations,
-so they can't read each others files. Many applications use no VFS
-at all and have no way to access files on vfs shares. And the
-existence of multiple vfs implementations makes it unlikely that they
-will start using one.
-
-Gnome-vfs has no concept of Display Names, something which is very
-useful in a gui based system. In some places we auto-generate virtual
-desktop files to get this feature, but that is very hackish and need
-support in all apps to understand them. This is also quite closely
-related to handling filename charset encoding, another very weak point
-in gnome-vfs. The ideal way to reference a file is the actual real
-identifer on disk, database, remote share or what have you, as that
-can be passed between implementations, used with other access methods,
-etc. But to display something useful to the user you really need a
-user understandable utf-8 encoded string and a way to map that to/from
-the filename.
-
-There is no support for icons at the level of gnome-vfs. This means
-that all users above the vfs must implement it themselves (e.g. in
-nautilus and in the file selector). Each implementation have its own
-bugs, maintainance load and risk for different behaviour. It also
-means that vfs backends cannot supply their own icons, something which
-might be very useful for e.g. a network share based on some new fancy
-web service. 
-
-The abstraction that gnome-vfs use is very similar to the posix model,
-which is problematic in several ways. The posix model matches poorly
-with the sort of highlevel operations that gnome applications wants to
-do with the vfs. The vfs is not typically used for what I would call
-"implementation files", which are things like configuration files,
-data files shipped with apps, system files, etc, but rather for what
-I'd like to call "user document files". These are the kind of files
-you open, save, or download from the internet to look at. Applications
-that use these would like highlevel operations that match the kind
-of operations you use on them, like read-entire-file, save-file,
-copy-file, etc. 
-
-The posix model is also a bad match when implementing gnome-vfs
-modules. It requires some features from the implementation that can be
-difficult or impossible to implement. For example, its not really
-possible to support seeking when writing to a file on a webdav share,
-because a webdav put operation is essentially just streaming a copy of
-the new file contents. We currently work around this by locally
-caching all the file data being written and then sending it all in the
-close() call. This is clearly suboptimal for a lot of reasons, like
-applications not expecting close() to take a long time, and not
-checking its error conditions very closely.
-
-Another problem is that the posix model doesn't contain explicit
-operations for some of the things applications need to do. So instead
-applications rely on well known knowledge of the behaviour of posix
-to implement these operations. However, such behaviour might not be
-guaranteed on some gnome-vfs backends. A common example is the atomic
-save operation. A typical way to implement this on posix is to write
-to a temporary file in the same directory, and then rename over the
-target file, thus guaranteeing an atomic replacement of the file on
-disk, or a failure that didn't affect the original file. Of course,
-if a gnome-vfs application would use this and the backend was a
-webdav share to a subversion repository you would get some really
-weird versioning history in the repository for no good reason. If the
-backend had its own implementation of the save operation we could get 
-both optimal behaviour on each backend, and an application API that
-doesn't require arcane knowledge of the atomicity of renames.
-
-One of the most problematic aspects of gnome-vfs is its authentication
-framework. The way it works is that you register callbacks to handle
-the authentication dialog, and whenever any operation needs to do
-authentication these callbacks will be called. The idea is that a
-console application would register a set of callbacks that print
-prompts on the console, and a Gtk+ application would have a set of
-callbacks that displays dialogs. There is a set of standard dialog
-based callbacks in libgnomeui that you can install by calling
-gnome_authentication_manager_init(). From an initial look this seems
-like a reasonable approach, but it turns out that this creates a host
-of different problems.
-
-One problem is how you connect this to the application. A lot of
-people are unaware that you have to call gnome_auth_manager_init() to
-get authentication dialogs, or don't want to depend on libgnomeui to
-do so. So a lot of applications don't work with authentication. Those
-who do call it generally have pretty poor integration with the
-authentication dialogs. For instance, the general authentication
-dialogs can't be marked as parents of whatever dialog caused the
-authentication (because they have know whay of knowing what caused
-it), and all sorts of problems appear when there is a modal dialog
-displayed already.
-
-Another problem is the combination of blocking gnome-vfs calls and
-authentication. When calling a blocking operation like read() and it
-results in a password dialog we have to start up a recursive mainloop
-to display it. Not only is this unexpected for the application, it
-also brings with it all the type of reentrancy issues that we had in
-bonobo. Even worse, there is no way to make this threadsafe. To make
-it threadsafe the callback would have to take the gdk lock before
-doing any Gtk+ calls, but this would cause a deadlock if the
-application called it with the gdk lock held. If we don't take the
-gdk lock then you can't do blocking vfs calls on any thread but the
-mainloop, or you have to take the gdk lock on any gnome-vfs call.
-
-The authentication callbacks can appear at *any* gnome-vfs entry
-point, which makes it very hard to write gnome-vfs applications that
-don't accidentally trigger a lot of authentication dialogs. For
-instance, the tree sidebar in nautilus has to take particular care not
-to stat or otherwise look at the toplevel items until the user
-explicitly expands them, otherwise you'd get authentication dialogs
-every time you opened a window. Its also easy to get multiple
-authentication dialogs for the same entity.
-
-The way threads are used in gnome-vfs is problematic, both from the
-point of view of writing backends, and for users of the library. For
-users it forces the use of threading, even if the application doesn't
-use the asynchronous calls that use the threading. It also enforces
-the need for a gnome_vfs_init() function, as thread initialization
-must be done very early.
-
-For backend implementations the use of threads forces every
-backend to be threadsafe. Many of the backends are inherently single
-threaded, either because they use non-threadsafe libraries like the
-smb backend, or because the server being wrapped forces serialized
-access (like an ftp backend where you really only want one connection
-to the server). 
-
-Backends run in context of the application using gnome-vfs, which can
-be a gtk+ app, but as well a console application, so they have no
-control or guarantee of their environment. For instance, they cannot
-rely on the existance of a mainloop, so there is no way to use
-e.g. timeouts to handle invalidation of caches. One way we have tried
-to solve this is to move some backends to the gnome-vfs daemon, where
-they can rely on the existance of the mainloop.
-
-Gnome-vfs use something called "gnome vfs uris" to identify
-files. These are similar, but not entierly identical to the types of
-uri used in webbrowsers. For instance, we often make us our own types
-of URIs when there is no official standard for them (although such
-standards might appear later, with incompatible behaviour). We also
-have a "well defined" posix-like type of behaviour that isn't the same
-as for web uris. The most extreme example would be mailto:, but even
-things like ftp:// uris are different. The ftp uri rfc explains how
-ftp:///dir/file.txt refers to $(login_dir)/dir/file.txt, and that you
-have to use ftp:///%2fdir/file.txt to refer to the absolute path
-/dir/file.txt on the server. Clearly we can't have pathname handling
-semantics that vary depending on the backend (no app would get it
-right), so we ignore the rfcs on this.
-
-Then there is the thing with escaping and unescaping uris. Although
-technically not very complex it is just are very hard to get right all
-the time. Among the most common questions on the gnome-vfs list is
-what the various escape/unescape functions does, what arguments has to
-be escaped, and how to display uris "nicely" (i.e. without escapes,
-although that makes them invalid uris). This is made extra complicated
-due to the poor handling of filename encodings and display names, and
-the fact that only "less common" cases (like spaces in filenames)
-break if you get it wrong.
-
-Last but not least, the fact that gnome-vfs uses something called a
-"uri" gives people the wrong impression of what the library is
-designed for. It causes people to complain when it doesn't have some
-support for mailto: links, and it makes people want support for
-cookies, extra http headers and other things typically used by a web
-browser. This isn't really the kind of use that vfs is targeted at. A
-library specific to that sort use would probably fit these apps much 
-better. 
-
-Most gnome-vfs state is tied to the application that uses it, which I
-think is quite unexpected by the user. For instance, when you log into
-a network share in nautilus and then click on a file to open it, the
-opening  application will have to re-connect and re-authenticate to
-the share, much to the users surprise. I really think most people
-expect a login like that is somehow session global. We do sometimes
-misuse gnome-keyring to "solve" the authentication issue, but even
-then we still have multiple connections to the network share, which
-can cause problem, for instance with ftp shares that use round-robin
-dns where the mirrors aren't fully sync:ed up. Again, some backends
-(smb) are now in the daemon which solves this issue.
-
-gnome_vfs_xfer() is possibly the worst-API call in the whole gnome
-platform. Its a single, buggy, do-it-all function with shitloads of
-combinations of flags and arguments to do all sort of things, with
-little or no semantic specifications or testcases. Its also to a large
-extent unnecessary for most applications and could easily be part of
-the file manager instead of a generic library. I'm also not sure that
-the "first do preflight calculation, then execute operation" model it
-uses is right. It is inherently racy, since the target or source could
-easily change during the preflight, and it makes error reporting and
-handling much more complicated. 
-
-The behaviour of symlink resolution in the UI has been discussed many
-times. Should clicking on a symlink "foo" in $dir go to $dir/foo or to
-the target directory. The Nautilus maintainers has decided that the
-best way to approach this is to have symlinks be used for "filesystem
-implementation" (like a symlink for /home -> /mnt/hdb2) and thus not
-be resolved on activation. However, we should (this hasn't been
-finished yet) support a different form of links (called "shortcuts" in
-the UI) that always resolve on activation. At the moment there is no
-support for anything like that in gnome-vfs, so we abuse desktop files
-for this. We even generate virtual in-memory desktop files in the smb
-backend to get this behaviour. Proper support for shortcuts in the
-vfs API would let apps automatically work without ugly desktop file
-hacks.
-
-Over the years gnome-vfs has accumulated a lot of cruft. It links to a
-lot of libraries, including openssl, gconf+ORBit2, avahi, dbus, popt,
-libxml, kerberos, libz and libresolv. Very few applications need all
-of these, yet every application that uses gnome-vfs links to all of
-them. Furthermore, some of the functionallity in gnome-vfs, like the
-wrapper for dns-sd, resolving, network utilities, ls parsing
-functions, ssl support, pty handling are perhaps not best suited for a
-vfs library, nor do they always have great apis and quality
-implementations. We could definately clean this up and minimize the
-APIs.
-
-At some point in time gnome_vfs_uri_is_local() started detecting and
-returning TRUE for NFS mounts and other type of local network
-mounts. This is both slow and unexpected, and has led to problems and
-unnecessary changes in many places. 
-
-The way the cancellation API for asynchronous operations is set up
-creates races and fragile code. The main issue is that if you call
-cancel before the operation callback has been called the callback will
-not be called. However, the callback typically wants to free some sort
-of user_data object passed to it, so that has to be handled also when
-you call cancellation. Couple this with the fact that there is no
-destroy notifies and you can't cancel after the operation callback has
-been called and you get an extremely tricky setup of combined
-callbacks. Furthermore, if threads are used there are some inherent
-races wrt detecting if the callback has been called when cancel is
-called, making it essentially impossible to get this right.
-
-There are also a bunch of issues with the current gnome-vfs that could
-technically be fixed like support for hidden file flags,
-backend-extensible metadata, no standard vfs dialogs like progress
-bars, etc.
-
-Last week I started thinking about a new design for a gnome-vfs
-replacement that would solve most of these issues, and at the same
-time gives a correct ordering of the platform stack. I've come up with
-a highlevel architecture that I think will work, even though I haven't
-yet finished it in detail or gotten the API totally worked out. Its
-somewhat of a radical departure from gnome-vfs as it is today, so
-brace with me as I try to explain the model and the ideas behind it.
-
-The gnome-vfs model is what I would call stateless. You can at any
-time throw a URI at it and it will do everything required to access
-the location. There is no need to, nor is there a way to set up
-anything like a "session" with a remote share. Of course, in practice
-this is not the way network shares work, so all sorts of session
-initiation, caching and other magic happens under the covers to make
-it look stateless. This is the source of all the problems with the
-gnome-vfs authentication model.
-
-I'd like to propose using a stateful model, where you have to
-explicitly initiate a session ("mount" a share) before you can start
-accessing files. This will give a well specified time when all forms
-of authentication will happen, when applications expect it and when
-they can use a more expressive and suitable API for this kind of
-operation. The actual i/o operations will then never cause any sort of
-authentication issues, and can thus be purely non-graphical
-(i.e. glib-only apps can do i/o). I imagine all/most actual mounting
-of shares will happen in the file manager and the file selector, or at
-gnome-session startup, so applications don't really need to handle
-this themselves.
-
-Not only is the model stateful. I'd like all state to be session
-global. That is, all mounts and network connections are shared between
-all applications in the session. So, if you pass a file reference from
-one app to another there is no need to log in again or anything like
-that. I think this is what users expect.
-
-Having a global stateful model means all non-local vfs accesses go
-through the vfs daemon. This works pretty well with the smb backend in
-the current gnome-vfs, and smb is the backend most likely to have high
-bandwidth traffic, so this doesn't seem to be a large performance
-problem. Although we do have to take the performance aspect into
-consideration when designing the daemon.
-
-In order to avoid all the problems with threading described above the
-vfs daemon will not use threads. In fact, I think the best approach is
-to let each active mountpoint be its own process. That way we get
-robustness (one mount can't crash the others) and simplify the backend
-creation greatly (each backend fully controls its context). It also
-will let us do concurrent access to e.g. two smb shares (like a copy
-from one to the other). We can't really do this atm since the thread
-lock in the smb backend serializes such access. But with two smb
-processes this is not a problem.
-
-There might be an issue with using separate processes for the
-mountpoints bloating up the desktop, but I don't think that it will be
-much of a problem. None of these processes will use the gui libraries
-that are the real sources of unshared dirty memory use. I tried a
-simple process that just used gobject and ran a mainloop. It only used
-78k of dirty memory. Also, each server need only link to and
-initialize the few libraries it needs, further keeping memory use down
-and avoiding bloat in all applications (e.g. apps need not link to
-openssl). 
-
-As a consequence of the stateful model we don't need the stateless
-properties that URIs has as identifier. To avoid all the problems
-comming from the use of URIs  we use a much simpler form of
-identifier. Namely filenames, in a hierarchical tree with
-mountpoints. These filenames are from an extended set of strings that
-includes the set of normal filenames, but also includes some platform
-dependent extensions. On win32 the full set might be some form of
-stringified version of the ITEMIDLIST from the windows shell api, and
-on unix we would use some out of band prefix to mark a non-local
-filename.  
-
-For example, we could be to use "//.network/" as a prefix for the vfs
-filename namespace. A smb share might then be accessed as
-"//.network/smb/computer:share/dir/file.txt", or a ftp share as
-"//.network/ftp/alex@ftp.gnome.org/dir/file.txt". With a setup like
-"//.network/$method/$mount_object/" it would be quite easy to find the
-process handling the mount. Just ask for a dbus named object like
-"org.glib.gvsf.smb.computer:share". It is also very easy to detect
-local filenames and short-circuit to in-process i/o.
-
-These filenames would be the real identifier for the files, and as
-such not really presentable to the user as it. You'd need to ask for
-the display name via the vfs to get a user readable utf8-encoded
-string for display. 
-
-The set of operations on files and folders would be both simplified
-and extended. We'd remove complicated things like read+write access to
-a file, and give less posix-like guarantees. We also make seek and
-truncate support optional in the backend. But then we will extend the
-set of operations possible to allow things like copy on the remote
-side (to avoid a download+upload operation on copy) and to have 
-a set of highlevel operations that applications want, like "save" that
-implements the best way to save for each particular backend.
-
-We support metadata like display name, mimetypes, icon, and some
-general information like length and mtime. But we make support for
-getting the full "struct stat" buffer backend optional, as that isn't
-a good abstraction for most backends. Also, the API will be designed
-on the idea that network latency is expensive, so that there will only
-be one call to stat() or readdir() needed to read all the metadata
-requested by the application. (Whereas posix will have readdir return
-only the names and force you to stat each file in a separate
-roundtrip.)
-
-We likely don't want the full gnome/unix vfs implementation in
-glib, instead glib will only ship an implementation of the vfs API for
-local file access, and one that communicates to the vfs
-daemon(s). Then we ship the daemon and the implementations of the
-various backends externally.
-
-We will also write a single gnome-vfs backend that allows access to
-all the glib vfs shares by using a uri like gvfs:///XXX that just maps
-to //.network/XXX. We can also implement a similar backend for kio so
-that kde applications can read and write to the shares.
-
-Furthermore, if FUSE is supported on the system we can write a FUSE
-filesystem so that we can access the files as $HOME/.network/XXX. This
-can be made extra nice if the application (like e.g. acrobat) uses
-the gtk+ file selector but not the vfs by having the file selector
-detect a filename like this and reverse-mapping it into a vfs pathname
-and use the vfs for folder access. 
-
-I've been doing some initial sketching of the glib API, and I've
-started by introducing base GInputStream and GOutputStream similar to
-the stream objects in Java and .Net. These have async i/o support and
-will make the API for reading and writing files nicer and more
-modern. There is also a GSeekable interface that streams can
-optionally implement if they support seeking.
-
-I've also introduced a GFile object that wraps a file path. This means
-you don't have to do tedious string operations on the pathnames to
-navigate the filesystem. It also means we can use the openat() class
-of file operations when traversing the filesystem tree, avoiding some
-forms of races when we do things like recursive copies.
-
-To support the stateful model and still have some form of caching we
-will also need to add some cache specific api so that you can trigger
-a reload of information from a directory. Otherwise a reload operation
-in the file manager wouldn't always get the latest state on something
-like a ftp share where we cache things aggressively.
-
-I have some initial code here for some of the basic APIs, but its far
-from finished and I'd like to spend some more time working on it
-before I present it. However, I think the general architecture is
-pretty sound and in a state where it can be discussed.
-
-Hopefully this description of my plans is enought to make people
-understand some of my ideas and allow us to start and discussion about
-the future of gnome-vfs. Also, consider it a heads up that I and other
-people will likely be working on this this in the future.
diff --git a/txt/vfs-names.txt b/txt/vfs-names.txt
deleted file mode 100644
index 25833d7c..00000000
--- a/txt/vfs-names.txt
+++ /dev/null
@@ -1,142 +0,0 @@
-Local filenames (in utf8 mode)
-1) standard: /etc/passwd
-2) utf8 and spaces: "/tmp/a åäö.txt" (encoding==utf8)
-3) latin-1 and spaces: "/tmp/a åäö.txt" (encoding==iso8859-1)
-4) filename without encoding: "/tmp/bad:\001\010\011\012\013" (as a C string)
-5) mountpoint: /mnt/cdrom (cd has title "CD Title")
-
-Ftp mount to ftp.gnome.org
-(where filenames are stored as utf8, this is detected by using
- ftp protocol extensions (there is an rfc) or by having the user
- specify the encoding at mount time)
-
-6) normal dir: /pub/sources
-7) valid utf8 name: /dir/a file öää.txt
-8) latin-1 name: /dir/a file öää.txt
-
-Ftp mount to ftp.gnome.org (with filenames in latin-1)
-9) latin-1 name: /dir/a file öää.txt
-
-backend that stores display name separate from real name. Examples
-could be a flickr backend, a file backend that handles desktop files,
-or a virtual location like computer:// (which is implemented using
-virtual desktop files atm).
-
-10) /tmp/foo.desktop (with Name[en]="Display Name")
-
-special cases:
-ftp names relative to login dir
-
-Places where display filenames (i.e utf-8 strings) are used:
-
-A) Absolute filename, for editing (nautilus text entry, file selector entry)
-B) Semi-Absolute filename, for display (nautilus window title)
-C) Relative file name, for display (in nautilus/file selector icon/list view)
-D) Relative file name, for editing (rename in nautilus)
-E) Relative file name, for creating absolute name (filename completion for a)
-   This needs to know the exact form of the parent (i.e. it differs for filename vs uri).
-   I won't list this below as its always the same as A from the last slash to the end.
-
-This is how these work with gnome-vfs uris:
-
-   A                                                     B                             C                             D        
-1) file:///etc/passwd                                    passwd                        passwd                        passwd   
-2) file:///tmp/a%20%C3%B6%C3%A4%C3%A4.txt                a åäö.txt                     a åäö.txt                     a åäö.txt
-3) file:///tmp/a%20%E5%E4%F6.txt                         a ???.txt                     a ???.txt (invalid unicode)   a ???.txt
-4) file:///tmp/bad%3A%01%08%09%0A%0B                     bad:?????                     bad:????? (invalid unicode)   bad:?????
-5) file:///mnt/cdrom                                     CD Title (cdrom)              CD Title (cdrom)              CD Title
-6) ftp://ftp.gnome.org/pub/sources                       sources on ftp.gnome.org      sources                       sources
-7) ftp://ftp.gnome.org/dir/a%20%C3%B6%C3%A4%C3%A4.txt    a åäö.txt on ftp.gnome.org    a åäö.txt                     a åäö.txt
-8) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt             a ???.txt on ftp.gnome.org    a ???.txt (invalid unicode)   a ???.txt
-9) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt             a åäö.txt on ftp.gnome.org    a åäö.txt                     a åäö.txt
-10)file:///tmp/foo.desktop                               Display Name                  Display Name                  Display Name
-
-The stuff in column A is pretty insane. It works fine as an identifier
-for the computer to use, but nobody would want to have to type that in
-or look at that all the time. That is why Nautilus also allows
-entering some filenames as absolute unix pathnames, although not all
-filenames can be specified this way. If used when possible the column
-looks like this:
-
-   A
-1) /etc/passwd
-2) /tmp/a åäö.txt
-3) file:///tmp/a%20%E5%E4%F6.txt
-4) file:///tmp/bad%3A%01%08%09%0A%0B
-5) /mnt/cdrom
-6) ftp://ftp.gnome.org/pub/sources
-7) ftp://ftp.gnome.org/dir/a%20%C3%B6%C3%A4%C3%A4.txt
-8) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt
-9) ftp://ftp.gnome.org/dir/a%20%E5%E4%F6.txt
-10)/tmp/foo.desktop
-
-As we see this helps for most normal local paths, but it becomes
-problematic when the filenames are in the wrong encoding. For
-non-local files it doesn't help at all. We still have to look at these
-horrible escapes, even when we know the encoding of the filename.
-
-The examples 7-9 in this version shows the problem with URIs. Suppose
-we allowed an invalid URI like "ftp://ftp.gnome.org/dir/a åäö.txt"
-(utf8-encoded string). Given the state inherent in the mountpoint we
-know what encoding is used for the ftp server, so if someone types it
-in we know which file they mean. However, suppose someone pastes a URI
-like that into firefox, or mails it to someone, now we can't
-reconstruct the real valid URI anymore. If you drag and drop it
-however, the code can send the real valid uri so that firefox can load
-it correctly.
-
-So, this introduces two kinds of of URIs that are "mostly similar" but
-breaks in many nonobvious cases. This is very unfortunate, imho not
-acceptable. I think its ok to accept a URI typed in like
-"ftp://ftp.gnome.org/dir/a åäö.txt" and convert it to the right uri,
-but its not right to display such a uri in the nautilus location bar,
-as that can result in that invalid uri getting into other places.
-
-Since I dislike showing invalid URIs in the UI I think it makes sense
-to create a new absolute pathname display and entry format. Ideally
-such a system should allow any ascii or utf8 local filename to be
-represented as itself. Furthermore it would allow input of URIs, but
-immediately convert them to the display format (similar to how
-inputing a file:// uri in nautilus displays as a normal filename).
-
-One solution would be to use some other prefix than / for
-non-local files, and to use some form of escaping only for non-utf8
-chars and non-printables. Here is an example:
-
-   A
-1) /etc/passwd
-2) /tmp/a åäö.txt
-3) /tmp/a \xE5\xE4\xF6.txt
-4) /tmp/bad:\x01\x08\x09\x0A\x0B
-5) /mnt/cdrom
-6) :ftp:ftp.gnome.org/pub/sources
-7) :ftp:ftp.gnome.org/dir/a åäö.txt
-8) :ftp:ftp.gnome.org/dir/a \xE5\xE4\xF6.txt
-9) :ftp:ftp.gnome.org/dir/a åäö.txt
-10)/tmp/foo.desktop
-
-Under the hood this would use proper, valid escaped URIs. However, we
-would display things in the UI that made some sense to users, only
-falling back to escaping in the last possible case.
-
-The API could look something like:
-
-GFile *g_file_new_from_filename (char *filename);
-GFile *g_file_new_from_uri (char *uri);
-GFile *g_file_parse_display_name (char *display_name);
-
-Another approach (mentioned by Jürg Billeter on irc yesterday) is to
-move from a pure textual representation of the full uri to a more
-structured UI. For example the ftp://ftp.gnome.org/ part of the URI
-could be converted to a single item in the entry looking like
-[#ftp.gnome.org] (where # is an ftp icon). Then the rest of the entry
-would edit just the path on the ftp server, as a local filename. The
-disadvantage here is that its a bit harder to know how to type in a
-full pathname including what method to use and what server (you'd type
-in a URI). This isn't necessarily a huge problem if you rarely type in
-remote URIs (instead you can follow links, browse the network, add
-favourites, etc).
-
-I don't know how hard this is to do from a Gtk+ perspective
-though. Its somewhat similar to what the evolution address entry does.
-