> From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]]
> I've found that it's always easy to look back at a previously
> made design decision and question it, especially when one
> wasn't involved in the
> design discussion that weighed the current needs with the
> benefits and detriments of possible implementations.
---
At the time one makes decisions one cannot know what one will know in 5,2,1
years or 4 months time. At my last company,
large group made decision to go w 1 vendor out of 2 for a feature we
needed. Logically, choice #2 was better, though for some intangible reason (that I
couldn't justify) I felt safer with choice #1
even
though the facts didn't stack up in their favor. The group decided
to go with choice 2. Five months later, choice2 announced a law
suit with one of their suppliers that had been ongoing for about 6-8 months (i.e. they
knew they were in trouble when negotiating
with
us but were hoping to get our money to tide them through the financial rough waters
until they could legally force their supplier to
live up to expectations...). It killed the project for our company -- the other
company got wind of our deal and now had almost
doubled the price and the critical product timing window would be
about 80% closed by the time we'd be able to get a release from
company #1.
In retrospect, I can see more logically, why I felt the way
I did -- we had more experience and work history with #1 even though they had some
known and recurrent issues. I felt more
comfortable with the known 'evil' that I felt we could safeguard against vs. the
unknown "snake-oil" sales people from company #2.
Also #2 had a
*very* polished marketing pitch, while company #1 had virtually no marketing -- almost
all engineers. That also figured into my
"feeling": if you have two small companies, both have limited
resources to produce the same product and prices are in the same
range. Then if one has really snazzy presentations vs. the
others have more raw presentations looking like engineer written
documentation (vs. tech pubs), which company do you think is
more likely to have resources to complete an engineering project?
> Rethinking a design decision
> isn't bad of course but it's always easier to see more
> alternatives in
> hindsight than it is at the time. Some of the reason more
> options are
> generally 'obvious' in hindsight is because there is more
> infrastructure in place that would support these options.
> That's not always the case at the time a feature is
> implemented.
---
Absolutely...just the idea of mentioning 'mount' or even
the idea of NFS or an 'automounter' -- they aren't the first things one would be
thinking about in an environment where you don't
even have a self-hosted, compiler yet.
That's one reason I think long term project planning is
a waste to devote *too* much detail towards. You don't know
what the state of the art will be in 2 years -- or what new tools will be available,
or whatever. You just do the best you can
at the time -- designing things as modularly and bullet proof
as you can so you can more easily re-use code with minimal
changes in new features in un-anticipated ways. Using the reasoning "well it wasn't
designed for that" doesn't help you alot when
all you wanted to do was write an email *now* to your stock broker
to 'sell'. You get to have your sale or you don't. The market doesn't care. There
is no 'good guy/bad guy', blame is irrelevant.
The only thing that is relevant is if you sold your stock or not.
Suffice it to say there was
> precedent for the '//<drive' syntax (I believe MKS did this
> or was it O/S 2?) and pseudo device support was very much in
> it's infancy. But these are not the only reasons this syntax
> came into being. The main reason was because somebody wanted
> it and then implemented it. It addressed the need of being
> able to easily access all available drives without the user needing
> to explicitly set up mount entries. Obviously, while folks
> using Cygwin in general liked the notion of not having to
> mount drives explicitly, there were enough who found the
> conflict with the '//<computer name>/<share>' syntax of UNC
> paths a problem to prompt making a change to something that allowed
> both benefits (the current '/cygdrive/<drive letter>'
> convention). You may
> be able to find some threads of this whole discussion and
> development in the
> email archives if you're interested in doing a little
> digging. You might find that it answers allot of questions
> you have about Cygwin path handling. I'd start with 1997
> though if you're looking to pick up any threads that were
> at least close to the opening discussions.
---
I can see how the decision was made. I believe I _might_
have tried for a special prefix like /net/ -- a different
flavor of hack, but not without wide precedent: /debug, /proc,
/host (not really hardcoded, but defaulted)" etc.
But you're right in that you can never really say, for certain, what choices
one would have made because in the present,
one, irrevocably, has some knowledge of the present.
However the good news is that with the emphasis on applications maintaining
POSIX compatibility -- no one
should be *relying* on "//" having a special meaning.
That being the case, one could choose, in the present, to do a
simple hack (in the minimal case) to change the smb-share prefix
from "//<host/share>" to "/smb/<host/share>". Theoretically, this
should break nothing. unless they have hard-coded paths.
If transitioning of current CYGWIN customers who may have
hardcoded paths is a concern, then a transition plan could be
put into effect (dates TBD):
1) string in envvar CYGWIN, maybe, 'SMB_PRFX="//"'.
This could be added to any "update" if not defined, or
set as 'SMB_PRFX="/smb/"' in new installs or set
to SMB_PRFX="" by users who want to do their own mounting.
2) When automounting SMB shares is available, then can
default SMB PRFX="" in new installs. Warning in console
login shells of "SMB_PRFX" being deprecated in favor of
automount usage.
3) Base install includes smb-automount setup. Usage of SMB_PRFX
generates warning about being ignored/obsolete and to use
automount for smb references (with default "/smb").
4) ...after a few years...remove check for SMB_PRFX...
Steps can be skipped/merged; it may be decided that it is a non-issue and just do it.
For Win32 paths -- again, going with full Win32 compatibility
seems logical since it is the only standard that assigns
meanings to ":\" usage in the Win32 world. Again, if *really*
needed, one could use a similar transition plan to allow
conversion of apps that make assumptions about C:foobar not
having the standard Win32 meaning (as previously shown, this
is not a property of CMD, and is 'honored' (wherever it is
implemented) in, AFAIK, all of MS's programs.
Any issues only affecting Win32 path usage would be unlikely
to affect POSIX-compliant programs using preferred-character-set filenames.
Logical? Not asking, necessarily, that anyone implement it --
I'm only engaging in a concept discussion. Actual implementation --
well that may never happen, or may -- may be done by someone
expert in the various areas affected, or done by me (in all my loads of spare
time...*cough-cough*).
I'm trying to focus on what I believe would be useful for the
Cygwin toolset to allow for gnu-linux tool porting for the
purpose of using them interactively/transparently in a win32
environment _and_ providing a *nix-POSIX compatibility layer.
Thanks Larry for shedding some light on the past...it's easier to
see how we got here (wherever here is).
Linda
(and all I wanted to do was to find my favorite pen (being
used on something else) that was dropped in the swamp, that
needed to be drained anyway, for cleaning....; re: "up to ears in alligators")
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
