Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "linda w \(cyg\)" To: Subject: Hindsite, moving forward, concepts...? Date: Sat, 11 Jan 2003 14:07:11 -0800 Message-ID: <004001c2b9bd$ca7073c0$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4.3.1.2.20030111143529.036c3f08@pop.rcn.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h0BM7Q915785 > From: Larry Hall (RFK Partners, Inc) [mailto:lhall AT rfk DOT com] > 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 '// 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 '///' syntax of UNC > paths a problem to prompt making a change to something that allowed > both benefits (the current '/cygdrive/' > 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 "//" to "/smb/". 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/