On Wed, 13 Nov 2002 13:44:43 GMT, [EMAIL PROTECTED] (David Boyce) wrote
in news:4.3.2.20021113084209.01bc3240@;mail.boyski.com:
> The point has been made, and not yet refuted, that the best place to
> add this value would be as a File::Spec::Cygwin module. I happen to
> agree with that and would like to hear the counter-argument before a
> new namespace is added.
A certain amount of communication glitchyness has been plaguing my
attempts to get feedback since I first posted in [EMAIL PROTECTED]
and also in Cygwin's List; the connection between Cygwin's List and
Gmane, which I use to read these Lists, has been severed and no new
messages were showing up (at Gmane's end), for instance. I recommend that
all responses be CC:d direct to me (I guess to somian -AT- pobox -DOT-
com).
That said, I don't know where, when and by whom (I am guessing it was on
the Cygwin List, which I have been trying to keep checking by other
means) any mention was made of File::Spec::Cygwin. This message
[authored by David Boyce] is the first *I've* heard of the idea (that my
proposal relates to that module).
Several follow-up messages have followed this msg to which I am
replying, and have I think largely resulted in bringing to light the
mechanism by which the File::Spec modules 'do their thing' (which sounds
not dissimilar to what the ExtUtils::MM family does). This information
and the relative frozen-ness i perceive that the File::Spec module
system may have made me feel, as i think others will, that it is not
likely that I could easily convince that package's maintainer(s) to add
the functionality I am discussing --and it *would* require their
cooperation. Furthermore I am not sure how valuable it would be since
the semantics of Cygwin Perl use *internally* are simply those of any
basic *Nix system (POSIX, single-rooted hierarchy). It is only when we
need to have Cygwin Perl do what Perl is SO good at, what many feel is
its strongest suite -- _acting as glue or duct tape between disparate
applications_ -- that the problem domain my original post described is
revealed.
I don't think that what my proposed module does is a good fit with the
domain of File::Spec. You can already use File::Spec to get an absolute
path on Cygwin Perl (for example); you just cannot get it to give you
that path in any other *mode* than POSIX. But the outer environment in
which Cygwin is running is *not* a POSIX kind of OS and its applications
(and shells) don't understand POSIX file specs.
So, I don't find the proposal that what I am talking about belongs in
File::Spec very convincing anyway. File::Spec is an attempt to achieve a
certain kind of orthogonality amongst disparate kinds of operating
systems but includes no notion (that i can recall now, and I've used
File::Spec a lot) that *one single unique file* residing on the local
filesystem *can* have more than one correct, canonical, fully-specified
('absolute') *name*. Until and unless I can see a message in which
someone addresses that point I am unlikely to be convinced along these
lines.
A couple of additional points relating to the above are that while Perl
5.8.x may have additions to include greater Cygwin-specific code, 5.6.x
(I am developing on 5.6.1) and earlier will not. I'd like to release
something that could benefit those who for whatever reason aren't able
or willing to upgrade right away.
As far as namespace consumption goes, I'd say my proposal isn't very
greedy. Filesys:: already exists as a populated base. How ::CygwinPaths,
which i am proposing, would either pollute or waste that is not apparent
to me. Given that I think I've made my case (or as yet haven't seen
anyone directly refute it) that the problem domain my work addresses is
unique (doesn't fall into previously addressed categories) I think it
certainly deserves to be allocated to it.
Also, say my module's functionality was to be added to the
File::Spec::Cygwin module. Would it be distributed as part of that
bundle? It's going to add a non-trivial amount of weight (filesize,
complexity) to the package. There's XS code to be selectively processed
but only on the Cygwin platform (Makefile - build-config complexity
introduced), etc. I'm extremely unsanguine about attacking that sort of
task (the support of it). OTOH, I am not at all unenthusiastic about the
idea that the pieces I've introduced -- the interface to the Cygwin C
API is the core of it -- might get rolled into future releases of
*something* else (not sure what, yet). I suggest that what my module
does could become a part of future Cygwinperl releases, somehow. But
maybe why not let users pound on the code for a while as a separate,
user-added module, before trying to implement that? Then we collectively
might know more and better just what and how to do.
Anyway, thanks for all feedback so far, and I hope the logistical
communications-systems resistance I am experiencing at this end lets up
a bit so that i do not miss other feedback.
Soren A
