After some time away from GVfs I'm now back working on it. In order to
get people to start looking at it I'm sending this status report. I'll
also try to send more regular status reports in the future.
Yesterday I split the gvfs repository into two parts, "gio" and
"gvfs":
"gio" is an architectur
The last month or so I've continued my work on a gnome-vfs replacement
called gvfs. Its still nowhere near finished, but its getting to a
state where it might be interesting for people to look at and give
some feedback. So, here is a writeup on the current design and
codebase.
If you haven't read
I was going over this old posting and wanted to add some commentary.
In a perfect world, which we should try to achieve, of course, any such
passed uris would be canonical and resolvable within scope of both
machines. That is, full host names should be passed and both boxes
should be able to resol
Hey Alex,
On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote:
> After some time away from GVfs I'm now back working on it. In order to
> get people to start looking at it I'm sending this status report. I'll
> also try to send more regular status reports in the future.
> If we want to use
On Tue, 2007-09-04 at 11:03 +0100, Bastien Nocera wrote:
> Hey Alex,
>
> On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote:
> > After some time away from GVfs I'm now back working on it. In order to
> > get people to start looking at it I'm sending this status report. I'll
> > also try to
Le mardi 04 septembre 2007, à 11:03 +0100, Bastien Nocera a écrit :
> Hey Alex,
>
> On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote:
> > After some time away from GVfs I'm now back working on it. In order to
> > get people to start looking at it I'm sending this status report. I'll
> >
On Thu, 2007-09-13 at 18:01 +0200, Vincent Untz wrote:
> Le mardi 04 septembre 2007, à 11:03 +0100, Bastien Nocera a écrit :
> > Hey Alex,
> >
> > On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote:
> > > After some time away from GVfs I'm now back working on it. In order to
> > > get peop
Hi,
What about nautilus? At what point would it be ported, and are things
going to be weird if an app is using gvfs and nautilus gnome-vfs, or
vice versa?
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listi
On Thu, 2007-09-13 at 12:23 -0400, Havoc Pennington wrote:
> Hi,
>
> What about nautilus? At what point would it be ported, and are things
> going to be weird if an app is using gvfs and nautilus gnome-vfs, or
> vice versa?
I plan to branch nautilus soon and start porting it to gio. Some time
nex
On Thu, 2007-09-13 at 18:01 +0200, Vincent Untz wrote:
> > Would it be completely out of the question to have a GTK+ release for
> > the sake of gio/gvfs?
>
> With the GNOME release team hat on my head: I think there's a big
> interest in using gvfs in 2.21, but it'd be nice to know at the
> begin
Hi,
There's a lot of code to absorb here, a minor comment, I might expect
GUnixFileInputStream/GWindowsFileInputStream rather than
GLocalFileInputStream.
I haven't found the relevant code yet to see what it does, but a nice
property would be to set close-on-exec by default for all streams.
A mor
On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote:
> Hi,
>
> There's a lot of code to absorb here, a minor comment, I might expect
> GUnixFileInputStream/GWindowsFileInputStream rather than
> GLocalFileInputStream.
Well, the same class is used on both unix and windows. Its the
implementat
On Fri, 2007-09-14 at 09:37 +0200, Alexander Larsson wrote:
> > A more macro thought, since there's so much code here, it would be
> > worth spending some time to try and identify the parts an app (vs. a
> > file manager) would usually use, and then somehow highlight those
> > parts in the docs and
Hi Alex,
On 9/14/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > There's a lot of code to absorb here, a minor comment, I might expect
> > GUnixFileInputStream/GWindowsFileInputStream rather than
> > GLocalFileInputStrea
On Fri, 2007-09-14 at 08:16 -0400, Dominic Lachowicz wrote:
> Hi Alex,
>
> On 9/14/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote:
> > > Hi,
> > >
> > > There's a lot of code to absorb here, a minor comment, I might expect
> > > GUnix
Hi,
On 9/14/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> Well, the same class is used on both unix and windows. Its the
> implementation of "native files", and I don't see any need to split it
> out really. What differences would there be between the two?
>
My impression is that ideally on
On 9/4/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> If we want to use gvfs in Gnome 2.21 there are two possibilities:
> 1) Release next glib before the next Gtk+ release
> 2) Temporary ship gio in a separate module, which we later move to glib
> (pkg-config should magically make this work
On Fri, 2007-09-14 at 10:47 -0400, Havoc Pennington wrote:
> Hi,
>
> On 9/14/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> > Well, the same class is used on both unix and windows. Its the
> > implementation of "native files", and I don't see any need to split it
> > out really. What differenc
Alexander Larsson wrote:
> On Fri, 2007-09-14 at 10:47 -0400, Havoc Pennington wrote:
>
>> Hi,
>>
>> On 9/14/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
>>
>>> Well, the same class is used on both unix and windows. Its the
>>> implementation of "native files", and I don't see any need
On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote:
> On 9/4/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
>
> > If we want to use gvfs in Gnome 2.21 there are two possibilities:
> > 1) Release next glib before the next Gtk+ release
> > 2) Temporary ship gio in a separate module, which we
Yevgen Muntyan wrote:
>>> My impression is that ideally on Windows you use the native
>>> windows-looking file API, and that the file-descriptor-using API is
>>> some kind of weird emulation hack. But I could not comment
>>> intelligently on the details.
>>>
>> I assume so. Its part of the lib
> The issue is that file descriptors shouldn't be passed from a dll / exe
> using one C runtime to another using a different C runtime -- or if they
> are, they must be used only with functions from the appropriate C
> runtime. Use of file descriptors within a single dll is generally not a
> probl
Hi!,
On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote:
> I think doing a glib release for 2.21 with gio is at least worth discussion,
> but as was already mentioned, it would probably be good to have some
> real-life experience with the api in the form of nautilus and file-chooser
> por
On Tue, 2007-09-25 at 00:11 +0200, Carlos Garnacho wrote:
> Hi!,
>
> On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote:
>
>
>
> > I think doing a glib release for 2.21 with gio is at least worth discussion,
> > but as was already mentioned, it would probably be good to have some
> > real
Hi!,
On Tue, 2007-09-25 at 09:02 +0200, Alexander Larsson wrote:
> On Tue, 2007-09-25 at 00:11 +0200, Carlos Garnacho wrote:
> > Hi!,
> >
> > On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote:
> >
> >
> >
> > > I think doing a glib release for 2.21 with gio is at least worth
> > > disc
On Thu, February 15, 2007 10:54, Alexander Larsson wrote:
> One thing that I'm especially unsatisfied
> with is the naming. There is just way too many "vfs", "daemon" and
> "dbus" all over the place.
Speaking of which:
> GInputStream
> GInputStreamSocket
> GFileInputStream
> GOutputStream
>
On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> In general I think that we will still use URIs to pass file references
> between apps when doing things like DnD, cut-and-paste or when saving
> filenames in config files. It seems hard to change this at this time,
> and it has some adva
On Thu, 2007-02-15 at 11:19 -0500, Dimi Paun wrote:
> On Thu, February 15, 2007 10:54, Alexander Larsson wrote:
>
> > One thing that I'm especially unsatisfied
> > with is the naming. There is just way too many "vfs", "daemon" and
> > "dbus" all over the place.
>
> Speaking of which:
>
> > GInpu
On Thu, 2007-02-15 at 17:31 +0100, Xavier Bestel wrote:
> On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> > In general I think that we will still use URIs to pass file references
> > between apps when doing things like DnD, cut-and-paste or when saving
> > filenames in config files. I
On Thu, 2007-02-15 at 17:45 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-15 at 17:31 +0100, Xavier Bestel wrote:
> > On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> > > In general I think that we will still use URIs to pass file references
> > > between apps when doing things lik
Hi Alex,
Alexander Larsson wrote:
> ...
> GIO
> ===
>
> 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
On Thu, 2007-02-15 at 17:52 +0100, Xavier Bestel wrote:
> On Thu, 2007-02-15 at 17:45 +0100, Alexander Larsson wrote:
> > While a laudable idea I'm not sure this is practical, at least not as
> > the main approach. If I drag a directory from nautilus to some other
> > apps, do you really want to t
Le jeudi 15 février 2007 à 18:57 +0100, Alexander Larsson a écrit :
> > Well, if the 2 apps don't sit on the same computer, what else could you
> > want ?
> > Of course, as an optimization if the 2 apps are "local to each other",
> > they should just use the current behavior.
>
> Actually, its mor
On Thu, 2007-02-15 at 17:32 +0100, Alexander Larsson wrote:
> > You probably thought about it already, but why not
> > GSocket{Input|Output)Stream?
> >
> > In general I think naming works good if the interface is named with the
> > abstract concept, and the implementation is named:
> >
> >
On Thu, 2007-02-15 at 19:32 +0200, Stefan Kost wrote:
> Hi Alex,
> > GCancellable
> > GFile
> > GInputStream
> > GInputStreamSocket
> > GFileInputStream
> > GOutputStream
> > GFileOutputStream
> > GOutputStreamSocket
> > GSeekable
> > GFileInfo
> > GFileEnumerator
> > GMountOperation
> > G
On Thu, 2007-02-15 at 20:17 +0100, mathieu lacage wrote:
> On Thu, 2007-02-15 at 17:32 +0100, Alexander Larsson wrote:
>
> > > You probably thought about it already, but why not
> > > GSocket{Input|Output)Stream?
> > >
> > > In general I think naming works good if the interface is named with the
On Fri, 2007-02-16 at 08:35 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-15 at 19:32 +0200, Stefan Kost wrote:
> > Hi Alex,
>
> > > GCancellable
> > > GFile
> > > GInputStream
> > > GInputStreamSocket
> > > GFileInputStream
> > > GOutputStream
> > > GFileOutputStream
> > > GOutputStre
On Fri, February 16, 2007 02:45, Alexander Larsson wrote:
> I guess this makes some sense. The disadvantages is that its not as
> obvious which implementations of an interface there are (its not as easy
> as GInputStream*), but its clearly much easier to read.
>
> I'm fine with changing this. What
Alexander Larsson wrote:
> The last month or so I've continued my work on a gnome-vfs replacement
> called gvfs. Its still nowhere near finished, but its getting to a
> state where it might be interesting for people to look at and give
> some feedback. So, here is a writeup on the current design an
On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> In general I think that we will still use URIs to pass file references
> between apps when doing things like DnD, cut-and-paste or when saving
> filenames in config files. It seems hard to change this at this time,
> and it has some adv
On Mon, 2007-02-19 at 18:04 -0600, Hans Petter Jansson wrote:
> On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> > 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
On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> Apps talk to the main daemon using the session bus, but most file
> operations are done using direct peer-to-peer dbus connections between
> the
> clients and the mount daemons. Just send a request over the session
> bus to set up such a
On Fri, 2007-02-16 at 09:13 -0500, Dimi Paun wrote:
> On Fri, February 16, 2007 02:45, Alexander Larsson wrote:
> [ about new API names ]
>
> I'd like to second this -- it's the smart thing to do IMO.
> Other well known APIs (Java, .NET, Win32) use a similar naming
> pattern, and despite it's funct
On Tue, 2007-02-20 at 21:46 -0500, David Zeuthen wrote:
> On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> > Apps talk to the main daemon using the session bus, but most file
> > operations are done using direct peer-to-peer dbus connections between
> > the
> > clients and the mount da
On Mon, 2007-02-19 at 17:27 +0100, nf2 wrote:
> Alexander Larsson wrote:
> > The last month or so I've continued my work on a gnome-vfs replacement
> > called gvfs. Its still nowhere near finished, but its getting to a
> > state where it might be interesting for people to look at and give
> > some
(adding Havoc to Cc since there's a few D-Bus questions here. For
context, the original questions about D-Bus and session bus forwarding
is here
http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00092.html
On Wed, 2007-02-21 at 10:56 +0100, Alexander Larsson wrote:
> > How do you a
Hi,
David Zeuthen wrote:
>
> Actually, as mentioned on IRC, TCP/IP transport been in D-Bus for a long
> time, it's just not hooked up by default on the session bus nor
> forwarded by e.g. ssh yet. You asked about how auth will work; that's a
> good question... Havoc, can you shed some light on th
On Wed, 2007-02-21 at 22:12 -0500, Havoc Pennington wrote:
> ssh forwarding would work for DBUS_SESSION_BUS_ADDRESS exactly as it
> does for DISPLAY, and would also encrypt/compress the protocol stream.
> The problem of course is that someone has to patch ssh.
Yea, so this wouldn't even require
On Wed, 2007-02-21 at 23:20 -0500, David Zeuthen wrote:
> On Wed, 2007-02-21 at 22:12 -0500, Havoc Pennington wrote:
> > ssh forwarding would work for DBUS_SESSION_BUS_ADDRESS exactly as it
> > does for DISPLAY, and would also encrypt/compress the protocol stream.
> > The problem of course is tha
David Zeuthen wrote:
> Writing this patch and getting it into openssh sounds like great Google
> Summer of Code project for the D-Bus project.
All the changes would be to openssh though. Probably a first step is
just ask on the openssh mailing list.
> [1] : such as /var/lib/dbus/machine-id - btw
Since the last report I've mainly been working on the sftp backend,
which now is mostly working. There are some minor details left which can
be seen in the TODO list at the top of "gvfsbackendsftp.c".
To help with the sftp backend I also added GDataInputStream and
GDataOutputStream to gio. These h
On Tue, 2007-02-20 at 09:24 +0100, Alexander Larsson wrote:
[Snip]
> In general, the way mountpoints work in unix is that they are mounted
> over *one* directory, and don't mix things up with other mounts, so I
> think the best solution would be to have each mountpoint be one
> subdirectory under
On Tue, June 12, 2007 3:51 pm, Jerome Haltom wrote:
> I want to make sure this takes NFS mounted home directories into
> consideration. I think perhaps ~ is a very poor choice of location for
> this.
Why would ~ be a poor choice? The GVFS system would not be responsible
for mounting home director
On Thu, 2007-02-22 at 17:39 -0500, Sean Middleditch wrote:
> Just a reminder that : is the separator used in the PATH environment
> variable, and is thus a poor choice for use in directories.
>
> In all honesty, if the intended use case for reading the directory info
> is for FUSE and GVFS, I thin
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
> This won't work. We need to be able to extract all the mount information
> from the path, so that if the app stores the path across sessions, say,
> in "recent documents", the FUSE layer will know what to do when it's
> accessed later
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
> However, the first method you describe:
>
> ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
>
> sounds perfect. It's rich (we can get back the mount info later),
> extensible (we don't have to figure out the entire
On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
>
> > This won't work. We need to be able to extract all the mount information
> > from the path, so that if the app stores the path across sessions, say,
> > in "recent docu
On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote:
> On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
>
> > However, the first method you describe:
> >
> > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
> >
> > sounds perfect. It's rich (we can get back the m
On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote:
> > On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
> >
> > > This won't work. We need to be able to extract all the mount information
> > > from the path, so tha
On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote:
> On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
> > However, the first method you describe:
> >
> > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
> >
> > sounds perfect. It's rich (we can get back the mou
On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote:
> > You're probably always going to need type, server and share though, so
> > maybe you can make it a bit more readable:
> >
> > ~/.mounts/smb:$server:$share/dir/file.txt
> >
On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote:
> > On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote:
> > As a further example of this I tried OSX. It has a system similar to the
> > first proposal. I.E. When you m
On 2/22/07, Hans Petter Jansson <[EMAIL PROTECTED]> wrote:
> ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
I just want to point out that there's a freedesktop specification for
where things should be stored. Not many seem to respect it, but I,
for one, really would appreciate
On Thu, 2007-02-22 at 12:49 -0600, Hans Petter Jansson wrote:
> On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote:
> > On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
>
> > > However, the first method you describe:
> > >
> > > ~/.mounts/type=smb-share;server=$server;share=$shar
On Thu, 2007-02-22 at 14:22 -0600, Hans Petter Jansson wrote:
> On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote:
> > On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote:
>
> > > You're probably always going to need type, server and share though, so
> > > maybe you can make it a bit m
On Thu, 2007-02-22 at 14:51 -0600, Hans Petter Jansson wrote:
> On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote:
> > In fact, its likely they implement this by just stat()ing all the files
> > in the recent list. This is a great example of where automounting would
> > royaly screw things
On Thu, 2007-02-22 at 22:26 +0100, Nikolai Weibull wrote:
> On 2/22/07, Hans Petter Jansson <[EMAIL PROTECTED]> wrote:
>
> > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
>
> I just want to point out that there's a freedesktop specification for
> where things should be stored.
Just a reminder that : is the separator used in the PATH environment
variable, and is thus a poor choice for use in directories.
In all honesty, if the intended use case for reading the directory info
is for FUSE and GVFS, I think it would be a lot cleaner to just put some
kind of user-friendly na
68 matches
Mail list logo
