home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 970 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Fri, 12 Jan 96 18:34:41 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Protection bits
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.460c@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 10 Jan 96 "marcel Offermans" wrote to All:
  14.  
  15.  >>> When I come to think of it this doesn't seem all that hard to do and it
  16.  >>> would probably not even slow down the filesystem. I mean, taking a peek
  17.  >>> at the first 512 bytes as it is written shouldn't be that hard. The
  18.  >>> only trouble is that 512 bytes might not be sufficient to make a
  19.  >>> FileID...
  20.  
  21.  >> But that basically would be the same as having the contents of an .info
  22.  >> file as the first block of EVERY file...  Which I think is the basic idea
  23.  >> on the Mac (I don't fully understand the "data" and "resource" forks but
  24.  >> if the "resource" fork is a block at the start of the file that IDs the
  25.  >> file type and the program that generated it...).  I, personally, prefer
  26.  >> files to be PURE files; not some hybrid that requires tricks to transfer
  27.  >> to other users.
  28.  
  29.  mO> Either you misunderstood John or I did. I don't think John meant that
  30.  mO> the first 512 bytes should be made into a file ID, he simply suggested
  31.  mO> that looking at the first 512 bytes of any file should be enough to
  32.  mO> identify the file (in most cases).
  33.  
  34.  mO> The file type could then be stored somewhere in the FileInfoBlock, for
  35.  mO> example.
  36.  
  37. Yes, that's what I meant.
  38.  
  39.  mO> If we expand this idea a little further, it could be the start of a
  40.  mO> more object oriented view on files. For each type, you could define a
  41.  mO> couple of actions, like "view", "edit", "print" and associate them to
  42.  mO> your favourite picture viewer, word processor, etc. Now if this can be
  43.  mO> merged with the datatypes features of the OS, it would make a very nice
  44.  mO> extension.
  45.  
  46. Sure, the OS and other programs are free to use this extra information in the
  47. FileInfoBlock for whatever purpose.  It could also be used for the 'show all
  48. files' option of Workbench, it could associate the proper icon with each file
  49. according to its FileType real quickly.  Same goes for FileRequester which for
  50. example only allows you to select a JPEG picture or some other FileType, all
  51. files with the wrong FileType are filtered out.
  52.  
  53. And because the filesytem handles the FileTyping itself, all files 'stored' on
  54. the disk will automatically get the right FileType as soon as they are copied
  55. to the disk.  No need to pass this information onto other computers in seperate
  56. files, or using a special archiver.  Any computer supporting this system can
  57. identify the files themselves as they are copied to the disk.
  58.  
  59. Grtz John
  60.  
  61. -----------------------------------------------------------------------
  62.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  63. -----------------------------------------------------------------------
  64. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  65.