SPUG: getting filesystem info? (a la File::Spec)

[dancerboy]

At 11:09 AM -0800 11/20/01, Matt Tucker wrote:
>-- dancerboy <dancerboy at strangelight.com> spake thusly:
>
>>  File::Spec does some of this, but not all.  I'd also like to do this
>>  in a more platform-independent way than File::Spec (i.e., as much as
>>  possible, I'd like the module to figure these things by directly
>>  querying the OS/filesystem, rather than relying on a database of how
>>  different OS's "should" behave.  For one thing, remote volumes may
>>  not behave as expected based on the local OS's filesystem
>>  conventions.)
>
>I'm not sure I really see the value in this. You're going to take a
>performance hit because you'll have to figure this out every single
>time you start up,

No: I'll only take the performance hit when a client requests 
information that the module doesn't already have.

>  and if you want to properly deal with remote volumes
>you'll take the hit again every time you write to a different directory.

True, but I think this module will be mostly useful to programs that 
need to write large numbers of files into a few directories, so the 
performance hit shouldn't be too bad, relative to the tasks for which 
the module is useful.

>
>Also, some of what you're trying to figure out seems difficult or
>impossible to do in a platform independent way.

True.  That's why I said "as much as possible" and not "completely". 
Also, I should have been more clear: because I asked these questions 
as part of preliminary research, I was listing my more ambitious 
feature-set.  Not all of these features have the same priority. 
E.g.: I think maximum file-name length and case-sensitivity are much 
higher priority than getting an exhaustive list of legal characters. 
(The latter is problematic because, as I think you were perhaps 
hinting at, it will be difficult to differentiate characters from 
meta-characters in a platform-independent way.)

>
>I would say that your development efforts would be better spent adding
>functionality to File::Spec, rather than writing another module that
>does the same thing in a different way.

Well, folding the functionality into File::Spec or not is mostly a 
matter of what namespace I decide to place my API into -- it doesn't 
really change the development effort in any significant way.

One problem with adding the functionality to File::Spec is that 
File::Spec isn't OO, whereas I think it makes sense for my module to 
use an OO interface.  My idea now is that each object will 
encapsulate information about a specific directory.

>  In addition to the added
>knowledge you're proposing (legal filename characters, etc.), you could
>add a feature that tests each assumption against the current filesystem
>(or even specified directory) to determine empirically whether the
>assumptions are correct. That way, the performance hit is only incurred
>for those who want it, and it's optimized as well.

Not sure what advantage this has over just doing the tests when the 
client requests the information.  I don't see any advantage to an API 
with two different methods, one for getting an answer, the other for 
getting a *correct* answer.  If a client cares enough to request the 
information in the first place, they probably care enough to want 
information that's actually useful...

-jason

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/