[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New VFS being developped for glib/Gnome
Gregg C Levine
RE: New VFS being developped for glib/Gnome
Fri, 20 Jul 2007 12:02:09 -0400
For those of us who are familiar with the other stored resource methods for
storing code, such as subversion, and CVS, but not very familiar with GIT,
please elaborate on how to retrieve the files stored there.
Gregg C Levine email@example.com
"The Force will be with you. Always." Obi-Wan Kenobi
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:bug-hurd-
> email@example.com] On Behalf Of Michael Banck
> Sent: Friday, July 20, 2007 9:39 AM
> To: firstname.lastname@example.org
> Subject: New VFS being developped for glib/Gnome
> just wanted to point out this presentation done by Alexander Larsson
> (RedHat) this week at GUADEC on GVFS:
> (temporary PDF version: http://oussik.com/guadec2007-gvfs.pdf )
> The code is at http://www.gnome.org/~alexl/git/gvfs.git/
> (I didn't manage to check it out yet, damn git)
> It is further down the stack than the old gnome-vfs (glib) and uses dbus
> and FUSE to extend the VFS.
> This might be something which could be much more naturally consumed by
> the Hurd than previous desktop VFS implementations, so maybe somebody
> wants to take a look at it. At this point, we can probably not propose
> large changes to the design anymore, though, but we could replace parts
> of it by Hurdish bits.
> <marcus> this seems like a design where the Hurd could support the VFS,
> rather than the VFS just ignoring everything under it
> <marcus> nice
> The original announcement `Plans for gnome-vfs replacement' is here:
> A detailed status report has been posted here:
> I'll repost parts of it inline for easier consumption:
> The gvfs code consists of three parts, a library "gio" which has the
> API that applications use, a set of daemons handling access to various
> file resources (only smb implemented atm), and a dynamic module that
> (optionally) gets loaded into gio that communicates with said daemons.
> The gio library is meant to be a part of glib. Its a generic I/O
> library similar to e.g. java.io.*. Its a "modern" gobject-based
> library using things like inheritance and interfaces. As such it can't
> be in the main glib library (since that doesn't link to gobject).
> Right now it contains these public classes:
> Some short explanations:
> GCancallable: all i/o operations optionally take one of these so
> that you can cancel the operation from another thread (for sync i/o)
> or from the mainloop (for async i/o).
> GFile: an abstract reference to a file. These are cheap to construct
> and handle (i.e. creating one doesn't do any i/o). Consider them an
> abstraction of a pathname. In fact, for local files they are just a
> filename. Generally we want to avoid handling strings like uris/and
> filenames in application code. It only leads to problems with things
> like filename escaping etc. The general approach is to construct a
> GFile from a filename or uri once, and then use things like
> get_parent() and get_child() to navigate the filesystem.
> GInputStream, GOutputStream: These are abstract stream base classes
> that support both sync and async i/o. For subclasses that only
> implement sync i/o there is a thread-based emulation of async
> i/o. Compare to java.io.InputStream or System.IO.Stream.
> GSeekable: Interface that streams of any type can implement if they
> support seeking.
> GInputStreamSocket, GOutputStreamStocket: stream implementation for
> regular sockets. Created them from a file descriptor. This is
> implemented because its used heavily in the daemon communication code.
> GFileInputStream, GFileOutputStream: Abstract subclass of the regular
> streams that add some features that streams from files typically have,
> like seek, tell, and fstat. All the operations on GFile that return a
> stream return a GFileStream.
> GFileInfo: An abstraction of struct stat. It has a few "hardcoded"
> attributes like type, name, size and display name. Then it has a
> generic key-value attribute system that allows any backend to expose
> its own (namespaced) attributes. (For instance, the local file backend
> exposes xattrs and selinux attributes this way.)
> GFileEnumerator: enumerates files inside a directory
> GMountOperation: object that handles the types of callbacks needed
> during a mount operation. You create one of these and connect to
> e.g. the ask_password signal and then pass it to the mount
> operation. When the mount operation needs to ask for a password the
> signal will be emitted. There will be a standard implementation of
> this in Gtk+ that displays authentication dialogs.
> GVfs: Base class for the virtual filesystem. Does mapping to/from
> filenames, paths and parse names. This is what gets switched out by
> the daemon module.
> The virtual filesystem as such is all run in session-wide daemons,
> that apps talk to. This has many advantages: state (like caches,
> authentication and charset settings) are shared between apps, we avoid
> lots of connections to a server, and each app need not directly
> link to all the weird i/o libraries needed. Of course, there is a risk
> for bloat, but I think we can keep it pretty small by being careful
> what the daemons link to.
> A large problem with gnome-vfs is that applications not specially
> coded to use gnome-vfs will not be able to read non-local files. A
> nice solution to this would be to use FUSE to let such apps use normal
> syscalls to access the files. In general its quite tricky to map any
> URI to a FUSE file, but with the mountpoint + filename setup gvfs uses
> it is very easy to create a FUSE filesystem that lets you access all
> the current vfs mounts.
> Bug-hurd mailing list