Re: semantics of gnome_vfs_get_file_info_from_handle

[Colin Walters <walters debian org>]

On Wed, 2003-02-12 at 04:41, Alexander Larsson wrote:

> Yes, but that is typically a local fstat which:
> a) is really fast (the data is cached in the kernel, needs no i/o)

True.

> b) doesn't get the mimetype which is what you want

True.

> c) the data you get from it is probably exactly the kind of data you don't
>    want to be stale (like file size).

But, you might want to open a file for reading, and also at the same
time get its size.  

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

Well, yeah...but it would be a one-time change.

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

Ok, I actually named it:
gnome_vfs_get_known_file_info_from_handle.  Could you see the patch I
posted to the list here?

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

Yeah.

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

How would I special-case this for http?