>Resource forks are not transparent to the user, I guess they just aren't because not many think of them and work with them and had them explained well. I remember when I first started learning about networks. The concept of ports for a long time was incomprehensible to me: "Well, I got the IP number, so what do I need that port number for? I know the machine. That's enough, right?" Most everybody on this list and definitely Eugene is gonna smile over this as for them and now for me ports have become second nature of who we are. (Well, something like that. (c:) But I find the similarities to files and resource forks quite similar: A file without a resource fork is like a server that has no different port addresses. Sure you can still setup different server processes on that machine, but every connection being made has to be sorted out exactly what server process it asks for. So for huge servers with lots of client-server applications going on it might just be better to run dedicated machines: One server process per machine. Same with a file: Say you have something that requires all kinds of different data ... text, sound, images, code. You can put all that into one file and work with it. But oh what a pain to find what you need in that stream of data. So you end up creating hundreds of files and you can address whatever item you need individually ... although they really only make sense if you keep them together. For servers the solution is ports: I got the IP, and what I need is an SSH connection, so #22, could you please stand up? No problem having thousands of different type connections running at the same time on one machine. For files the solution is "resources" or call it "file ports" if you will: I got the file name, now I need that "squeek" sound, so ID 3441, could you please stand up? No problem having thousands of individual items within one file. Another way I like to think of resource forks is like each file as a mini-database. Databases structure and group things together that belong together. It's not good to put each cell, each field into a separate file, although that would be technically possible. It's not even common anymore to put each record or table into a separate file. No, everything is grouped in tables and then there are even groups of tables related with each other. Sure, I could put each and everything in separate files. Early databases did the same. I don't know how old the concept of ports is, but maybe in the early days of networking there was indeed just one dedicated server to connect to. So to bring my point to an end: If people find resources "not transparent", then they might just not be used to it. People today still have problems understanding ports and (relational) databases. But are they a good thing? Yes. Yes, until somebody will think of something better. I think it's just the course of history that makes "file ports" (aka "resource forks") not transparent. If engineers had thought of relational databases, object oriented programming, and some other breakthrough paradigms before ... where would the public understanding of computing be today? Some group of programmers decided that the name of the file should define the type of data. These programmers are to blame that it is now second nature to people that a suffix indicates the data type. Now that should be confusing and not transparent for users! But it's not, just because they're used to it. Funny. Had the programmers decided that each file should start with a text portion of meta data, then nobody in their wildest dream would think that a name and a data type have anything to do with each other like size and data type have nothing to do with each other. Everybody would find it natural that to communicate data type to the OS they would have to change the text prefix in the file. If the OS would reference files by numbers and the name of the file were just part of that text portion, then users would grasp meta data even clearer and each OS could handle files as it wishes. But yes, we're not yet there. And we'll just have to live that some things will stay like they are for a long time because they have already been like this for a long time. It's actually easier for users who don't care about "transparent" or not in terms of a mental concept. If the app is just one file then that is super-transparent for my parents. "Hey, it's your browser, there it is." Now if they see a collection of files for what should just be "a browser" (read that as "one browser") that is so non-transparent to them. Uh, ah, looking for a cool one-liner to finish this up. Cannot think of one. Too bad. (c: Bjorn >Check out the Mac OS X email list FAQ >http://www.themacintoshguy.com/lists/X.html > >To unsubscribe, E-mail to: <X-Unix-off at lists.themacintoshguy.com> >To switch to the DIGEST mode, E-mail to ><X-Unix-digest at lists.themacintoshguy.com> >Need help from a real person? Try. ><X-Unix-request at lists.themacintoshguy.com> > >---------- >$14.99 Unlimited Nationwide Mac Dialup and Mac Web Hosting >from your Mac ISP >Serious Mac Internet Solutions From NineWire! http://macinternetaccess.com DVIator | Run Dual ADC displays on your G4 or just one on an older Mac! Dr. Bott | <http://www.drbott.com/prod/DVIator.html> Support | Support this list by clicking here before you buy! this List | http://www.themacintoshguy.com/support.html OS X News, Dr.Mac, Forums, Tutorials, Tips, Hints, FAQ?s - http://www.osxfaq.com -------------------------------------------------------------------------------- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. --------------------------------------------------------------------------------