Re: NFS/AFS and is_local

OK, even though it was the friendly Swedish guy who originally asked
these questions and I was just doing my poor imitation of a helpful
person, I'm interested now.

So I have to ask some questions...

On Tue, Nov 05, 2002 at 10:32:02AM +0000, Michael Meeks wrote:
> 	Anyway - the main thing I think is (perhaps) to expand the use of
> eel_vfs_has_capabilities () - since it's a bit late in the day to be
> folding in that level of API immaturity into gnome-vfs IMHO. I think we
> should work out what set of functionality we want in there - and then
> move it wholesale into gnome-vfs for 2.4.
> 	Some things that might be useful:
> typedef enum {
> } EelVfsCapability;
> gboolean  eel_vfs_has_capability  (const char           *text_uri,
> 				   EelVfsCapability      capability);
> 	I think (perhaps) it'd be better to abstract this somewhat further;
> towards a 'performance' enumeration something like:

This feels wrong. You're grouping too many access methods together here.
For example,

  eel_vfs_has_capability_uri (uri, EEL_VFS_CAPABILITY_IS_REMOTE_AND_SLOW)

returns 1 for an NFS mounted filesystem. Now, while my NFS filesystem at
work is certainly slower to access than my local ones, it's nothing
compared to a WebDAV access. The point I am making (poorly) here is that
I can't see why I care too much about FAST_REMOTE versus FAST_LOCAL,
except that a remote system might go away at some point.

Don't we really want to enumerate the capabilities that you might want
to perform (EEL_VFS_CAPABILITY_SAFE_TO_EXECUTE seems right on this
count)? My first cut might be

	- can I write to it,
	- do I trust it enough to execute from,
	- is it reasonable to poll regularly for changes (yes for local,
	  slightly less often for NFS, no for WeDAV),
	- is it slow to perform operations (possibly the same as the
	  last point)
	- ... [other ideas here]

Hmm. On second thoughts, maybe this is just your scheme with more
members in the enum.

> 	or somesuch; either way it needs more thought; we'd then want some sort
> of gconf stringv that would allow you to configure which paths / servers
> are special case 'local', 'fast remote' etc.

Yeah, that's not crazy. Future-proof, too.

I'm sort of just thinking out loud here and trying to keep the ball


I don't have a solution, but I admire your problem.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]