apr_finfo_t and David's port query

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: David Reid [mailto:dreid@jetnet.co.uk]
> Sent: Monday, November 06, 2000 10:16 AM
> 
> In APR we have a lot of cuntions that do get/set.  For each we have a
> _loacl_ and a _remote_ version, normally with very similar 
> code in each.
> Any serious objections to altering these functions to simply 
> take a flag to
> determine if we need local or remote?  I'd suggest adding
> 
> typedef enum {
>     APR_LOCAL,
>     APR_REMOTE
> } apr_interface_e;
> 
> Whilst I'm at it I'd like at add apr_port_t... :)

If you are doing what I expect you are doing (caching the IP addr,
port ID, etc) then +++1 :-)  Similar to why I'm abstracting the 
canon_name type.  It's not the transparent details I'm hiding (that's 
only part of it), but once we chug through the calls for one half 
of the details, why do so again?

I know we are arguing against optimizing now... but handing off 
anything but abstract types causes headaches later when we try 
optimizing.  I'm already hitting the wall with the now-opaque finfo 
structure, and I'm not happy about it.  Specifically, group and user
calls are expensive (they aren't part of stat on Win32), their types
are variable length byte arrays (SIDs), and the user, group and world
permissions are a nightmare (nearly 2 orders of magnitude slower than
the simple stat.)  Solid types will always be bad in any portability
library, especially APR (and its portability library, too :-)

In Win32, with finfo, we really want four groups of things:

1. stat the file for size, dates, and file type ()
2. resolve the inode, device and object type (pipe/dev/etc)
3. resolve the file's true name
3. resolve the owner or group
4. resolve the permissions of the owner, group or world

and, in totally non-unix fashion (but applicable to Mac OS X, etc):

5. resolve the permissions of any user or group

Either the 2nd or 3rd queries resolve the 1st, but there is no single
method to both resolve the device/inode and the true filename in the
same call.  The owner and group are expensive, and permissions are
mind-bogglingly so!

Doesn't that suck?

Do we go back to the abstract apr_finfo_t, or define a common subset 
(size as a quadword, inode as a dword, times as apr_time_t stamps)
with an abstract extension (unknown or very unportable things, 
such as true name, user id, etc?)

Re: apr_finfo_t and David's port query

[jlwpc1 <jl...@mail.earthlink.net>]

From: "William A. Rowe, Jr." <wr...@rowe-clan.net>

> In Win32, with finfo, we really want four groups of things:
> 
> 1. stat the file for size, dates, and file type ()
> 2. resolve the inode, device and object type (pipe/dev/etc)
> 3. resolve the file's true name
> 3. resolve the owner or group
> 4. resolve the permissions of the owner, group or world
> 
> and, in totally non-unix fashion (but applicable to Mac OS X, etc):
> 
> 5. resolve the permissions of any user or group
> 

Silly me,  if only there was a Windows programmer around to ask how the OS Win32 Shell Functions do a lot of this?   :)

JLW