Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!moravian.EDU!nicholaA From: nicholaA@moravian.EDU Newsgroups: comp.sys.apple Subject: Re: resource forks Message-ID: <8905231405.AA27983@batman.moravian.edu> Date: 23 May 89 14:05:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 68 >Maybe I am missing something, but it seems like basically resource forks are >just for making certain types of programming a little bit easier. Is this >basically it? I mean, I could write my program to read in all the text from >a text file, or put all the output text into a single module which could >be replaced with other languages - that would be no problem. I could write >my programs with the dialog placements in a particular module which, >using a program like genesys could be edited and recreated quite easily. In addition, part of the precept of resources is that they _transparently_ add this functionality to a gs/os program. The is no need to have a bunch of configuration files lying around which must be worried about by the user. That is, to most average users, it makes life easier. >So this is another programming construct to make life easier in some cases. >Not that that is bad - but it isnt adding truely new functionality to the >user as such, right? It adds new functionality in that it (usually) makes the user's life easier. Also, because it makes a programmer's life easier, we can crank out more of these slick programs that everyone likes, so in essence this provides more functionality to the user because there will be more programs available to use. >As for a lot of the replys to several of the expressed concerns about >resource files, my own reply is - it seems a shame to cause existing, fully >functional programs to no longer function for a programming construct. >For instance, I assume that I will not be able to upload or download forked >files with TIC, I wont be able to m>ove them or copy them with ECP8, kermit >wont be able to up or download the files, Zlink is out of luck, cat.doctor >(and the other prosel tools except for mr.fixit) wont be able to be blanketly >used on disks with forks on them, etc. In other words, most of the utility >software that I have paid for or have available for use will not work. it will work. it just won't work with forked files. it's not like the day you use your first forked file the earth will stop moving. >Instead, I have to find substitutes written in GS/OS for the software to >use at least for this special case. yes, you probably will. And, as an author of gs/os stuff, i hope you *DO*. >AND, I then have to wait until the authors of the GS/OS versions get around >to updating to handle forked files. Not necessarily. In most cases older software doesn't know about resource forks, and doesn't bother with them, and the same for the user. The few instances where a program will have to updated is when they move data from one place to another. (by copying, moving, telecom, whatever) >Or, I can go on working as I am not and just realize that there will be >features on my GS that I wont be able to use for a year or so. Yep. The choice is yours. At some point if *YOU* want to use the new features that will be available, *YOU* have to make a choice. It's *YOUR* responsibility. >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 andy ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit