Re: NFS/AFS and is_local

[Malcolm Tredinnick <malcolm commsecure com au>]

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 {
> 	EEL_VFS_CAPABILITY_SAFE_TO_EXECUTE,
> 	EEL_VFS_CAPABILITY_IS_REMOTE_AND_SLOW
> } 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:
> 
> 	FAST_LOCAL, FAST_REMOTE, SLOW_REMOTE

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
rolling.

Cheers,
Malcolm

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