Re: semantics of gnome_vfs_get_file_info_from_handle

[Alexander Larsson <alexl redhat com>]

On 4 Feb 2003, Colin Walters wrote:

> On Tue, 2003-02-04 at 04:11, Alexander Larsson wrote:
> 
> > I've been thinking some about this, and I'm not sure this is the right 
> > thing. Adding API and vfs-method functions complicates implementation and 
> > API and should be done very rarely.
> 
> In general I agree.
> 
> > This API would basically only be used for you to avoid doing an extra 
> > request on http sources when getting the mimetype, since you get that on 
> > open anyway. I don't see it being useful in any other way.
> 
> Actually I think the file method at least could also use it, since as I
> said before it does a stat anyways in the open call.

Yes, but that is typically a local fstat which:
a) is really fast (the data is cached in the kernel, needs no i/o)
b) doesn't get the mimetype which is what you want
c) the data you get from it is probably exactly the kind of data you don't
   want to be stale (like file size).
 
> > And since you get the info in the header when you open the stream that 
> > info should be pretty much up to date[1]. I think your initial proposal 
> > migh be better, at least for the http backend. For the file backend I'm 
> > not so sure, but the extra i/o is less problematic there.
> 
> There is actually a third alternative that I just thought of; create a
> new open method like:
> 
> GnomeVFSResult gnome_vfs_open_full (const char *uri,
> 				    GnomeVFSOpenMode mode,
> 				    GnomeVFSHandle **handle,
> 				    GnomeVFSFileInfo *info);
> 
> This would return any information gathered during the open along with
> the handle.  Now, we can implement the old gnome_vfs_open entirely in
> terms of this new one.  So the old open module method would be
> deprecated in favor of this, but we wouldn't lose backwards
> compatibility.
> 
> What do you think?

Of the proposed API extensions:
1) gnome_vfs_open_full
 Requires added complexity in every module for an optimization which is 
 mostly only important for http.

2) gnome_vfs_request_file_info_from_handle
 I like this the most (except the name), since its the least complexity 
 for methods, and most clearly expresses what this optimization is about.

3) New flag to GnomeVFSFileInfoOptions
 This is a really nasty hack that exposes this optimization to every user 
 and makes some flags only usable for some API calls.

But really, I see API additions as a last resort. I want the API to be 
really small and orthogonal, so I still think special casing this for http 
is the right thing to do. That would make the http case a lot faster, not 
really affect the local file case (you want the mimetype anyway, not the 
fstat data), not require new API (and the branching+unstable branch that 
goes with it), not require changes to apps to get the advantage of the 
optimization, and in general be a less confusing set of APIs.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an otherworldly umbrella-wielding waffle chef plagued by the memory of 
his family's brutal murder. She's a scantily clad thirtysomething lawyer with 
an evil twin sister. They fight crime!