Cherry@Frodo.MGH.Harvard.EDU (J. Michael Cherry) (11/10/90)
If you could pick between NFS or AppleShare based strictly on the protocols' performance and ease of use which method of network file sharing would you use between a Macintosh and a multiuser system like Unix or VMS. With NFS the Unix software is included with the operating system, with AppleShare the software is included with the Macintosh. On a VMS system neither NFS or AppleShare is included but both are commercially available. Which method would be the best from a technical point of view? If the primary computer to the end user is a Macintosh then I feel the AppleShare approach would be best because NFS does not provide the icon information. Please correct me if I am uninformed for I do not know much about either methods design. Mike Cherry cherry@frodo.mgh.harvard.edu Department of Molecular Biology Massachusetts General Hospital, Boston
doelz@urz.unibas.ch (11/10/90)
In article <4665@husc6.harvard.edu>, Cherry@Frodo.MGH.Harvard.EDU (J. Michael Cherry) writes: > If you could pick between NFS or AppleShare based strictly on the protocols' > performance and ease of use which method of network file sharing would you > use between a Macintosh and a multiuser system like Unix or VMS. With NFS > the Unix software is included with the operating system, with AppleShare > the software is included with the Macintosh. On a VMS system neither NFS > or AppleShare is included but both are commercially available. Which method > would be the best from a technical point of view? None. Depending on resources, all gateways we have tested so far lacked performance. The following options are available: HOST ----converter----- Mac Apple Share This would be CAP, PACER, ALISA, LANWORKS, HELIOS, etc. The drawback is that the host is bothered quite a bit. Further, the mac-like storage of resource and data forks makes it necessary to either split the files or to convert them somehow on the fly. Both is computationally expensive. HOST ----converter---- Mac NFS, or (cryptic) DECnet The poor Mac has lots of things to do and will be not really useful any longer. HOST ----smart converter---- Mac NFS Gator Box AppleShare The cheapest solution because a smart converter can serve a lot of macs and hosts, (and it even works with VMS/UCX/NFS). > > If the primary computer to the end user is a Macintosh then I feel the > AppleShare approach would be best because NFS does not provide the icon > information. Please correct me if I am uninformed for I do not know much > about either methods design. > The problem is that you can rarely afford all the methods and let your users have the choice. From a commercial point of view, I would cosider a reasonably equipped mac with a large disk to be the best file server. Even if you manage to get your giga disks on the mac, you can't really *work* with those things because the performance of both the network and the con- version software is slow and costy. The file transfer is something else, though. If you manage to get your users work without switching the protocols (e.g., nfs/appleshare) and let them work in 'native' language locally, the off-line file transfer can be o.k. to work with larger files across system boundaries. I tested some, and there are some performance differences, but for *transfer* those products are fine. Regards Reinhard
kdb@macaw.intercon.com (Kurt Baumann) (11/13/90)
In article <4665@husc6.harvard.edu>, Cherry@Frodo.MGH.Harvard.EDU (J. Michael Cherry) writes: > If the primary computer to the end user is a Macintosh then I feel the > AppleShare approach would be best because NFS does not provide the icon > information. Please correct me if I am uninformed for I do not know much > about either methods design. All of the NFS products that I have seen on the Macintosh give you icon information for the end user. Ours most assuredly allows you to see all files on the host as icons, you can move them, open them, do whatever you would like to do with them, just as if they were on a local mac disk. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
kdb@macaw.intercon.com (Kurt Baumann) (11/13/90)
In article <1990Nov10.100943.1166@urz.unibas.ch>, doelz@urz.unibas.ch writes: > This would be CAP, PACER, ALISA, LANWORKS, HELIOS, etc. > The drawback is that the host is bothered quite a bit. Further, the > mac-like storage of resource and data forks makes it necessary to > either split the files or to convert them somehow on the fly. Both > is computationally expensive. > > HOST ----converter---- Mac > NFS, or (cryptic) DECnet > First off, the host is not bothered as much as you might think. And it is usually only "bothered" once in a while. Our software allows the use of either AppleSingle or AppleDouble formats on the remote disk, this allows you to edit files with your favorite Mac word processor without screwing the remote file up, yes it does create a seperate file containing the formating information, but it only does that for those files that you actually go and edit. There is only one file, a desktop file, created at the outset of your connection. This file contains the information that the Mac finder needs in order to display the information you have come to expect on the Mac. As far as computationaly expensive for the Mac, what do you mean? Our software only handles file information upon initial startup and then whenever you actually do something to the file. This is not that great of a task. > The poor Mac has lots of things to do and will be not really useful any longer. > > HOST ----smart converter---- Mac > NFS Gator Box AppleShare This isn't even that true. The Mac is doing no more work in this case that it would if there were an AppleShare sever out there. The GatorBox is doing all of the work for you. Sure it might be slow at times, but that isn't the Mac being slow. It's the Mac waiting for the GatorBox to catchup. If the above were true, no one would ever use AppleShare for anything. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
lefty@TWG.COM (11/13/90)
mcsun!cernvax!chx400!urz.unibas.ch!doelz@uunet.uu.net writes: Message-ID: <9011121028.aa13928@Mercury.TWG.COM> >HOST ----converter----- Mac >Apple >Share > >This would be CAP, PACER, ALISA, LANWORKS, HELIOS, etc. >The drawback is that the host is bothered quite a bit. Further, the >mac-like storage of resource and data forks makes it necessary to >either split the files or to convert them somehow on the fly. Both >is computationally expensive. Ah, but the splitting of resource and data forks is necessary on _any_ non-Mac server, no matter how you're getting to it. The Mac's file structure is totally unique. Besides, using a format like AppleDouble is particularly "expensive". There's really no conversion involved: each fork of the file is treated as a stream of bytes. The disadvantage of this approach, as you say, is that the necessity of doing the bulk of the work on the host consumes relatively expensive resources. A further disadvantage is that AppleShare is available for a pretty limited set of host implementations. NFS is much more widely implemented. >HOST ----converter---- Mac > NFS, or (cryptic) DECnet > >The poor Mac has lots of things to do and will be not really useful any longer. I'd have to strongly disagree with this. Our Mac-based NFS client's throughput is quite good, even on machines like an SE or a Plus. NFS is a fairly straightforward protocol. While there _is_ some overhead involved in constructing the appropriate lies to tell the Macintosh file manager, what you're saying here is a gross overstatement. >HOST ----smart converter---- Mac >NFS Gator Box AppleShare > >The cheapest solution because a smart converter can serve a lot of >macs and hosts, (and it even works with VMS/UCX/NFS). Not really true at all. The break-even point of this approach versus a Mac-based client is at about 10-15 Macs. At this stage, your poor "smart converter" is going to find ityself getting just a tad overloaded. Performance suffers accordingly. By putting the client software onto the Mac itself, the bottleneck imposed by the intermediary converter is avoided. -- David N. Schlesinger (lefty@twg.com) Sr. Software Engineer The Wollongong Group 415/962-7100
doelz@urz.unibas.ch (11/13/90)
In article <273EDDB5.40D1@intercon.com>, kdb@macaw.intercon.com (Kurt Baumann) writes: > In article <1990Nov10.100943.1166@urz.unibas.ch>, doelz@urz.unibas.ch writes: .. >> The drawback is that the host is bothered quite a bit. Further, the >> mac-like storage of resource and data forks makes it necessary to >> either split the files or to convert them somehow on the fly. Both >> is computationally expensive. > > First off, the host is not bothered as much as you might think. And it is > usually only "bothered" once in a while. Our software allows the use of Depends on what you say is bother. We made a micro VAX use 40% of kernel for it :-) It is strictly not true that the host is unaffected. As long as you use such a model, the host WILL have to do some work, and, depending on load, it *will* bother you quite a bit. Alternatively, you can set the resources for the appletalk to low values, but, then, the users on the apple side complain. Vice versa, your VAX turns out to be a damned expensive Mac, and cant do much else. I agree on the fact that larger processors are not that much affected, but some load will be always there. One thing which is severely to be considered are parameters like the nonpaged pool, affected by the high load of extremely small packets on the controllers. > either AppleSingle or AppleDouble formats on the remote disk, this allows you > to edit files with your favorite Mac word processor without screwing the > remote file up, yes it does create a seperate file containing the formating > information, but it only does that for those files that you actually go and Allright, and others have single/double options as well. Even, for VMS, some have the translation option to STR_LF... But then, copy a folder containing 8000 files, and the RMS needs to create 1600 files. That will take its time ! > edit. There is only one file, a desktop file, created at the outset of your > connection. This file contains the information that the Mac finder needs in > order to display the information you have come to expect on the Mac. This one file is a beast in some implementations, and needs to be accomodated with file structure, protection, etc. On VMS its not that easy. > > As far as computationaly expensive for the Mac, what do you mean? Our software > only handles file information upon initial startup and then whenever you > actually do something to the file. This is not that great of a task. The wait times for transferring a dir information in icon style is tremendous. Same applies if you empty trash etc. This is because all Macs (exceptional the fx) use their motherboard for I/O. > it would if there were an AppleShare sever out there. The GatorBox is doing > all of the work for you. Sure it might be slow at times, but that isn't > the Mac being slow. It's the Mac waiting for the GatorBox to catchup. Sorry, this is a misunderstanding, you are correct at this point. > > If the above were true, no one would ever use AppleShare for anything. > You are perfectly right. AppleShare has its limitations. The issues given above apply severely on VAXes currently (Havent seen LANWorks so far - maybe its better) but also apply for UNIX hosts to some extent. We need to admit that AppleShare was meant for PCs and that better protocols for other machines are more suited for some purposes. > -- > Kurt Baumann InterCon Systems Corporation > 703.709.9890 Creators of fine TCP/IP products > 703.709.9896 FAX for the Macintosh. My benefit is that I have the choice between DECnet, NFS, FTP, AppleTalk, LAT, and a serial line (Kermit :-) ) if I need to transfer files - and, you won't believe it - I take whatever seems to be most appropriate to me. Each of the protocols and methods has advantages, and drawbacks, so I think its fair to play most effective as needed. ************************************************************************ Dr. Reinhard Doelz * EAN doelz@urz.unibas.ch Biocomputing * DECNET 48130::doelz Biozentrum der Universitaet * X25 psi%46211142::embnet Klingelbergstrasse 70 * FAX x41 61 256760 CH 4056 Basel * TEL x41 61 253880 ext 888 ************************************************************************
kenw@noah.arc.ab.ca (Ken Wallewein) (11/13/90)
One thing concerns me about Macs using NFS -- regardless of the method -- versus those using "true" AppleShare. I understand that the NFS protocol does not support locking by either byte or record. Is that true? If so, it would seem to make life pretty difficult for applications which need that functionality, as for shared write/update access to data bases. If I recall correctly, Tops has (or had) the same limitation, and that the lack of necessary licking facilities was the reason behind its highly publicised data base corruption problem. /kenw
lefty@TWG.COM (11/14/90)
> One thing concerns me about Macs using NFS -- regardless of the method -- >versus those using "true" AppleShare. I understand that the NFS protocol >does not support locking by either byte or record. Is that true? If so, >it would seem to make life pretty difficult for applications which need >that functionality, as for shared write/update access to data bases. You are correct that NFS, per se, does not support record locking. However, Sun has thoughtfully provided a Lock Manager with recent versions of NFS, which allows the inclusion of this functionality (assuming the LOCKD program or something like it is running). Our product will use LOCKD if it is present. However, as a part of the distribution for our Pathway Client NFS, we include a custom daemon called NFSAD which supports the following functions: o User authentication o File range locking o File access mode control (file sharing a la OpenDeny) o Name-to-number mapping for users and groups While the use of this daemon is not a requirement for the product to run, we do need it if you want to do things like range-locking, access-control support, etc. Hope this helps! -- David N. Schlesinger (lefty@twg.com) Sr. Software Engineer The Wollongong Group 415/962-7100
kdb@macaw.intercon.com (Kurt Baumann) (11/14/90)
In article <1990Nov13.091518.1171@urz.unibas.ch>, doelz@urz.unibas.ch writes: > In article <273EDDB5.40D1@intercon.com>, kdb@macaw.intercon.com (Kurt Baumann) writes: > > In article <1990Nov10.100943.1166@urz.unibas.ch>, doelz@urz.unibas.ch writes: > .. > >> The drawback is that the host is bothered quite a bit. Further, the > >> mac-like storage of resource and data forks makes it necessary to > >> either split the files or to convert them somehow on the fly. Both > >> is computationally expensive. > > > > First off, the host is not bothered as much as you might think. And it is > > usually only "bothered" once in a while. Our software allows the use of > > Depends on what you say is bother. We made a micro VAX use 40% of kernel for > it :-) It is strictly not true that the host is unaffected. > As long as you use such a model, the host WILL have to do some work, > and, depending on load, it *will* bother you quite a bit. Alternatively, you > can set the resources for the appletalk to low values, but, then, the users > on the apple side complain. Vice versa, your VAX turns out to be a damned > expensive Mac, and cant do much else. I agree on the fact that larger > processors are not that much affected, but some load will be always there. > One thing which is severely to be considered are parameters like the > nonpaged pool, affected by the high load of extremely small packets on the > controllers. > If your micro VAX is doing NFS for anyone else then you are adding no more than more users to your system. I don't think that you will be affected by a high load of small packets, as we send 8K packets, most of the time (dependant upon gateways, etc.). We are not using AppleTalk, unless you are talking about AppleTalk encapsulation of IP. This is why NFS and TCP/IP are better in this situation than AppleShare and AppleTalk. Let's use those standards that are already out there and running on most machines. You are correct in stating that it is not strictly true that the host will not be affected to some degree. The point I should have made was that if you are already using your host for NFS, adding Macs using NFS does not really bog the host down any more than it would be if you added more SUN users. On the other hand if you added AppleShare to your VMS or UNIX machine and you also had NFS running on it, yes you would experience an additional load to your host. Thats why we feel that in mixed environments you should use NFS on the Mac instead of AppleShare, it just makes more sense to us. > > either AppleSingle or AppleDouble formats on the remote disk, this allows you > > to edit files with your favorite Mac word processor without screwing the > > remote file up, yes it does create a seperate file containing the formating > > information, but it only does that for those files that you actually go and > > Allright, and others have single/double options as well. Even, for VMS, some > have the translation option to STR_LF... But then, copy a folder > containing 8000 files, and the RMS needs to create 1600 files. That will > take its time ! > This is the whole point of what I was trying to say. We only create two files for text files, and only when they are edited from the Mac. You are not really copying 16000 files if you have 8000. We don't go out and create a new file for every file on the disk, only those that you need to be doing something with. And if it is a file that you are only going to be using on the Mac, and not messing with from another system, then you can create it as an AppleSingle, so it is one file. So I agree, if we went out and created another file for every file on the system that we were going to look at then yes, you would have a point here. But that is not what happens with our NFS product, perhaps some implementations of AppleShare do this... > > edit. There is only one file, a desktop file, created at the outset of your > > connection. This file contains the information that the Mac finder needs in > > order to display the information you have come to expect on the Mac. > > This one file is a beast in some implementations, and needs to be accomodated > with file structure, protection, etc. On VMS its not that easy. > How is this handled with a UNIX to VMS NFS connection currently? You need no more than that. The Mac specific information is all that goes in here. With AppleShare you have more to do. Not that it is easy with NFS mind you. > > > > As far as computationaly expensive for the Mac, what do you mean? Our software > > only handles file information upon initial startup and then whenever you > > actually do something to the file. This is not that great of a task. > > The wait times for transferring a dir information in icon style is tremendous. > Same applies if you empty trash etc. This is because all Macs (exceptional > the fx) use their motherboard for I/O. > Minimal the way we do it. > > > > If the above were true, no one would ever use AppleShare for anything. > > > > You are perfectly right. AppleShare has its limitations. The issues given > above apply severely on VAXes currently (Havent seen LANWorks so far - > maybe its better) but also apply for UNIX hosts to some extent. We need to > admit that AppleShare was meant for PCs and that better protocols for > other machines are more suited for some purposes. > Right you are. AppleShare is for PC type machines, and should be put onto UNIX/VMS/etc.. That is why we are offering an NFS client for the Mac. Hope this is helpful to everyone. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
kdb@macaw.intercon.com (Kurt Baumann) (11/14/90)
In article <9493*kenw@noah.arc.ab.ca>, kenw@noah.arc.ab.ca (Ken Wallewein) writes: > One thing concerns me about Macs using NFS -- regardless of the method -- > versus those using "true" AppleShare. I understand that the NFS protocol > does not support locking by either byte or record. Is that true? If so, > it would seem to make life pretty difficult for applications which need > that functionality, as for shared write/update access to data bases. There is a beastie called "lockd" that takes this into account. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
rbrink@hubcap.clemson.edu (Rick Brink) (11/14/90)
Kurt, you seem to really know the NSF software. Where can I get (from you) some background on this product? I appreciate anything you might be able to forward. Thanks, R.Brink rbrink@hubcap.clemson.edu
hpoppe@ncar.ucar.edu (Herb Poppe) (11/14/90)
In article <274043EF.4F0E@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: > And if it is a file that you are only going to be using > on the Mac, and not messing with from another system, then you can create > it as an AppleSingle, so it is one file. Can I change: a) the data fork, b) the resource fork, c) both the data fork and the resource fork of an AppleSingle file on an NFS mounted volume? How do I indicate I want a file to be AppleSingle vs. AppleDouble? Can I have both AppleSingle and AppleDouble files in the same folder (directory)? Do you handle CR-to-LF translation of text files so that I can edit an NFS mounted text file from the UNIX side with UNIX tools and from the Mac side with Mac tools? If so, how do you decide when to do the translation? Herb Poppe hpoppe@ncar.ucar.edu NCAR (303) 497-1296 1850 Table Mesa Dr. Boulder, CO 80307-3000
BLI@psuvm.psu.edu (JEFF BRENDLE) (11/15/90)
I'd like some info too...sounds like a good product.
Thanks!
Jeff.
PSU CAC Senior Lab Op & Student Consultant
PSU Berks Computer Consultantdrg@mdaali.cancer.utexas.edu (David Gutierrez) (11/15/90)
Kurt/David, Two questions: 1. Does your Mac NFS product support Macs on LocalTalk? 2. Does your company offer site licenses for Mac NFS? Please respond via netnews of private mail, whichever you prefer. David Gutierrez drg@mdaali.cancer.utexas.edu "Only fools are positive." - Moe Howard
kdb@macaw.intercon.com (Kurt Baumann) (11/15/90)
In article <4318@lib.tmc.edu>, drg@mdaali.cancer.utexas.edu (David Gutierrez) writes: > Kurt/David, > > Two questions: > 1. Does your Mac NFS product support Macs on LocalTalk? > Yes. The only factor is how well the gateway will run, and that is dependant upon what the gateway companies do to handle certain conditions. Which I am confident they will do, some already are. > 2. Does your company offer site licenses for Mac NFS? > Yes, drop me mail with you snail address and I will get some information out to you. > Please respond via netnews of private mail, whichever you prefer. Since there seems to be such a high degree of interest I am going to repost our original press release to comp.newprod in the nxt day or so. So you might want to keep an eye out for it there. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
lefty@TWG.COM (11/15/90)
>Two questions: Message-ID: <9011141714.aa22337@Mercury.TWG.COM> >1. Does your Mac NFS product support Macs on LocalTalk? Yes, we certainly do. Many LocalTalk-to-Ethernet gateways have a problem with transfers of the maximum size that NFS support (8K), so we allow the user to optionally "throttle down" the maximum transfer size to 1K in order to avoid problems. We've tested against the Gatorbox, FastPath, Shiva's Ethergate, as well as our own MacGateway. Seems to work just fine... >2. Does your company offer site licenses for Mac NFS? Well, we will sell "license packs", basically a right-to-copy for 10, 20, 50, etc. copies at a reduced price. Contact us directly for more information. -- David N. Schlesinger (lefty@twg.com) Sr. Software Engineer The Wollongong Group 415/962-7100
morgan@JESSICA.STANFORD.EDU (RL "Bob" Morgan) (11/15/90)
OK, gentlemen, let's advance to the next phase of features in the Great Battle of the Mac NFS Clients and their Spokesmen. Do TWG and Intercon (or anyone else, for that matter) plan to offer either of: 1) a program interface to the mount function, so that I can write a program to automatically mount an NFS volume; 2) a Sun-RPC programming library and runtime support, so I can write RPC programs on my Mac to run over MacTCP. If so, approximately when? Also, I'll put in a plug for a Mac AFS client, which I think would be a truly wunnerful thing. But NFS will do for now. Thanks, - RL "Bob" Morgan Networking Systems Stanford -------
kdb@macaw.intercon.com (Kurt Baumann) (11/16/90)
In article <MacMS.16358.2749.morgan@jessica.stanford.edu>, morgan@JESSICA.STANFORD.EDU (RL "Bob" Morgan) writes: > > OK, gentlemen, let's advance to the next phase of features in the Great Battle > of the Mac NFS Clients and their Spokesmen. Do TWG and Intercon (or anyone > else, for that matter) plan to offer either of: > > 1) a program interface to the mount function, so that I can write a program to > automatically mount an NFS volume; > What is the demand for this? We can do it, but there are security issues that would need to be addressed. Please send me email about this. > 2) a Sun-RPC programming library and runtime support, so I can write RPC > programs on my Mac to run over MacTCP. > We will not comment on unannounced products. > If so, approximately when? > > Also, I'll put in a plug for a Mac AFS client, which I think would be a truly > wunnerful thing. But NFS will do for now. > What is the demand for this as well? AFS? -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
kdb@macaw.intercon.com (Kurt Baumann) (11/16/90)
In article <9160@ncar.ucar.edu>, hpoppe@ncar.ucar.edu (Herb Poppe) writes: > In article <274043EF.4F0E@intercon.com> kdb@macaw.intercon.com (Kurt > Baumann) writes: > > And if it is a file that you are only going to be using > > on the Mac, and not messing with from another system, then you can create > > it as an AppleSingle, so it is one file. > > Can I change: > > a) the data fork, > > b) the resource fork, > > c) both the data fork and the resource fork > > of an AppleSingle file on an NFS mounted volume? > Yes. Both can be changed in an AppleSingle file. > How do I indicate I want a file to be AppleSingle vs. AppleDouble? > Currently it is determined automatically, based on volume type and file type. > Can I have both AppleSingle and AppleDouble files in the same folder > (directory)? > Yes. > Do you handle CR-to-LF translation of text files so that I can edit an NFS > mounted text file from the UNIX side with UNIX tools and from the Mac side with Mac tools? > If so, how do you decide when to do the translation? > Yes, if it is a Macintosh text file we translate CR-to-LF when output and reverse on input. The UNIX text files are also treated this way. This allows you to use any Macintosh text editor or word processor to edit you UNIX files, and still be able to edit them from the UNIX side with no problem. (ie; you don't need a seperate editor on the Mac :-)). -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
geo@syd.dit.CSIRO.AU (George Bray) (11/16/90)
Kurt Baumann writes: >All of the NFS products that I have seen on the Macintosh give you icon >information for the end user. Ours most assuredly allows you to see all >files on the host as icons, you can move them, open them, do whatever you >would like to do with them, just as if they were on a local mac disk. What about the mapping of Mac Text files to UNIX? As I understand it, a Mac file ends lines with CR, whereas UNIX requires CR+LF. -- George Bray > Earthnet: peg:geo Telephone: +61-2-411-3222 Avante Systems > AppleLink: AUST0150 Facsimile: +61-2-415-2212 27 Albert Avenue > CompuServe: 72711,253 QuickMail: +61-2-415-2210 Chatswood 2067 AUSTRALIA > Internet: geo@syd.dit.CSIRO.AU Share and Enjoy
dorner@pequod.cso.uiuc.edu (Steve Dorner) (11/16/90)
In article <27430546.6B52@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: >Yes. Both can be changed in an AppleSingle file. With GREAT pain and suffering, right? Don't you have to rewrite practically the entire file in the worst case? So the entire file has to traverse the network twice (or does the NFS protocol allow you to tell the server to do some things locally?). AppleSingle is an icky way to run a filesystem, unless you KNOW you will only be playing with one fork, or so it seems to me. >> If so, how do you decide when to do the translation? >Yes, if it is a Macintosh text file we translate CR-to-LF when output and >reverse on input. The UNIX text files are also treated this way. Uh, how do you decide if a UNIX file is a text file? Or a mac file for that matter; there are some applications that create text files that have creators other than 'TEXT' (TeachText comes to mind)? Now, for my own question: Does your product work with MacTCP? If it does, I may be a customer. If it doesn't, I have suddenly lost interest... -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
rek@sei.cmu.edu (Bob Kubiak) (11/17/90)
In article <27430546.6B52@intercon.com> (Kurt Baumann) writes: >> Do you handle CR-to-LF translation of text files so that I can edit an NFS >> mounted text file from the UNIX side with UNIX tools and from the Mac side with Mac tools? >> If so, how do you decide when to do the translation? >> > >Yes, if it is a Macintosh text file we translate CR-to-LF when output and >reverse on input. The UNIX text files are also treated this way. This allows >you to use any Macintosh text editor or word processor to edit you UNIX files, >and still be able to edit them from the UNIX side with no problem. (ie; >you don't need a seperate editor on the Mac :-)). I wasn't sure if there was an answer to the "How do you decide when..." question in your answer. Can your product tell the difference between UNIX text files and binary files (say, with some sort of file extension mapping) or is everything created on the UNIX side interpreted as a text file (as the Gatorbox does)? And if there's no differentiation, is it possible to turn off this text translation. As an example, we use FrameMaker on UNIX systems as well as Macintoshes. If people try to edit or copy the UNIX-created (binary) FrameMaker files from their Macintosh via the Gatorbox, unless translation is off the files get "translated" on their way over, hosing them up but good. Some other products (we won't mention here) do this translation automatically, don't make distinctions between types of UNIX files, and don't allow the text translation to be turned off. This can make working with cross-platform applications that generate/use binary files less than fun (can you say "FTP"?). _Bob Kubiak Software Engineering Institute Carnegie Mellon University rek@sei.cmu.edu
lefty@TWG.COM (11/17/90)
Steve Dorner writes: > >In article <27430546.6B52@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) >writes: >>Yes. Both can be changed in an AppleSingle file. > >With GREAT pain and suffering, right? Don't you have to rewrite practically >the entire file in the worst case? So the entire file has to traverse >the network twice (or does the NFS protocol allow you to tell the server to do >some things locally?). > >AppleSingle is an icky way to run a filesystem, unless you KNOW you will only >be playing with one fork, or so it seems to me. Yeah, we pretty much agreed with you on this one. Too much overhead and agita involved in supporting AppleSingle. Bottom line: we dont do it. If theres sufficient demand (we havent seen it yet) well consider it, but I think a better solution would be a UNIX utility to convert those pesky AppleSingle files into AppleDouble format. >>> If so, how do you decide when to do the translation? >>Yes, if it is a Macintosh text file we translate CR-to-LF when output and >>reverse on input. The UNIX text files are also treated this way. > >Uh, how do you decide if a UNIX file is a text file? Or a mac file for that >matter; there are some applications that create text files that have creators >other than 'TEXT' (TeachText comes to mind)? Again, our product doesnt fiddle with EOL conversion for exactly this reason. I would imagine that Intercon is using the execute bit to "determine" what is and isn't a text file; in my view this is both suspect and risky. We offer a TeachText work-alike called NetText, which tries to be a little intelligent about EOL conversion: it determines the EOL convention in force and will translate to another if requested to do so. Safer all around, to my way of thinking. >Now, for my own question: Does your product work with MacTCP? If it >does, I may be a customer. If it doesn't, I have suddenly lost interest... Of course it does. I wouldnt have it any other way. David N. Schlesinger (lefty@twg.com) | Sr. Software Engineer | "And you may ask yourself, The Wollongong Group | 'How do I work this?'" 415/962-7100 |
Reid Ellis <rae@gpu.utcs.toronto.edu> (11/18/90)
In <MacMS.16358.2749.morgan@jessica.stanford.edu>
morgan@JESSICA.STANFORD.EDU (RL "Bob" Morgan) writes:
2) a Sun-RPC programming library and runtime support, so I can
write RPC programs on my Mac to run over MacTCP.
For now you could use the MacTCP socket library available via FTP at
madhaus.toronto.edu.
Also, I'll put in a plug for a Mac AFS client, which I think
would be a truly wunnerful thing. But NFS will do for now.
Doesn't the "Appleshare" chooser document do that? Or do you mean
some sort of library for your software?
I would guess that an NFS client would be just another chooser device/
document.
[we need a better name for chooser documents -- choosedev? (a la
cdev)]
Reid
--
Reid Ellis 176 Brookbanks Drive, Toronto ON, M3A 2T5 Canada
rae@gpu.utcs.toronto.edu || rae%alias@csri.toronto.edu
CDA0610@applelink.apple.com || +1 416 446 1644kdb@macaw.intercon.com (Kurt Baumann) (11/20/90)
In article <1990Nov16.155133.15932@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > In article <27430546.6B52@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: > >Yes. Both can be changed in an AppleSingle file. > > With GREAT pain and suffering, right? Don't you have to rewrite practically > the entire file in the worst case? So the entire file has to traverse > the network twice (or does the NFS protocol allow you to tell the server to do > some things locally?). > > AppleSingle is an icky way to run a filesystem, unless you KNOW you will only > be playing with one fork, or so it seems to me. > We handle this algorithmically (much as it is done in Apple A/UX). We do this in order to cut down on the clutter on the UNIX side and in order to be compatible with A/UX built file systems. This way you can use the same file system from either A/UX or MacOS with NFS/Share. > >> If so, how do you decide when to do the translation? > >Yes, if it is a Macintosh text file we translate CR-to-LF when output and > >reverse on input. The UNIX text files are also treated this way. > > Uh, how do you decide if a UNIX file is a text file? Or a mac file for that > matter; there are some applications that create text files that have creators > other than 'TEXT' (TeachText comes to mind)? On the UNIX side we determine by the contents of the file (and this does not make it slow). On the Mac it is determined by a list of types that we consider to be text. > Now, for my own question: Does your product work with MacTCP? If it > does, I may be a customer. If it doesn't, I have suddenly lost interest... > -- Yes, until something better comes along we will support MacTCP, and even after that. > Steve Dorner, U of Illinois Computing Services Office > Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
kdb@macaw.intercon.com (Kurt Baumann) (11/20/90)
Most of the below I have already answered in another note, but I thought that I would respond to some of the TWG responses directly. In article <9011161241.aa27485@Mercury.TWG.COM>, lefty@TWG.COM writes: > Steve Dorner writes: > > > >In article <27430546.6B52@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) > >writes: > >>Yes. Both can be changed in an AppleSingle file. > > > >With GREAT pain and suffering, right? Don't you have to rewrite practically > >the entire file in the worst case? So the entire file has to traverse > >the network twice (or does the NFS protocol allow you to tell the server to do > >some things locally?). > > > >AppleSingle is an icky way to run a filesystem, unless you KNOW you will only > >be playing with one fork, or so it seems to me. > > Yeah, we pretty much agreed with you on this one. Too much overhead and > agita involved in supporting AppleSingle. Bottom line: we dont do it. If > theres sufficient demand (we havent seen it yet) well consider it, but I > think a better solution would be a UNIX utility to convert those pesky > AppleSingle files into AppleDouble format. > First, we feel and will always feel that people using a Macintosh don't really want to be bothered with the nitty grity, they want something that works, looks, and acts like it should on a Mac. To those ends, we would NEVER in a million years consider having a Mac user have to log onto UNIX and manipulate files with a "pesky" utility. :-) There are those users who are able to use both UNIX and a Mac, but the majority of users only know how to use a Mac. Second, why didn't you at least give the user the ability to read AppleSingle? > >>> If so, how do you decide when to do the translation? > >>Yes, if it is a Macintosh text file we translate CR-to-LF when output and > >>reverse on input. The UNIX text files are also treated this way. > > > >Uh, how do you decide if a UNIX file is a text file? Or a mac file for that > >matter; there are some applications that create text files that have creators > >other than 'TEXT' (TeachText comes to mind)? > > Again, our product doesnt fiddle with EOL conversion for exactly this > reason. I would imagine that Intercon is using the execute bit to > "determine" what is and isn't a text file; in my view this is both suspect > and risky. We offer a TeachText work-alike called NetText, which tries to > be a little intelligent about EOL conversion: it determines the EOL > convention in force and will translate to another if requested to do so. > Safer all around, to my way of thinking. > The only way you could read a Mac text file written by TWG's NFS would be to do the following: a. convert the file b. edit the file c. convert the file back (ever try reading a file with VI that contains too many characters on a single line?) The way we do this, all you need to do is step b (edit the file). I can see why you thought this, as this is they way TWG does it. We don't look at the execute bit as many scientific datasets do not have the bit set, yet are binary; and some files have the bit set but are text files (such as login, etc.). NetText is, IMHO, a hack. Why would a Mac user want to use a special text editor to edit files on the NFS side, when they should be able to use the editor that they are familiar with. For exactly this reason, we decided to provide invisible text file conversion. > >Now, for my own question: Does your product work with MacTCP? If it > >does, I may be a customer. If it doesn't, I have suddenly lost interest... > > Of course it does. I wouldnt have it any other way. > Neither would Apple :-). I am not trying to start a flame war, but I did want to point out a fews things here, that were supposition on TWG's part. Hopefully this helps to clarify those few guesses. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.