home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / acorn / tech / 1386 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  4.2 KB
  1. Path: sparky!uunet!comp.vuw.ac.nz!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!jwil1
  2. Newsgroups: comp.sys.acorn.tech
  3. Subject: Translink type protocols...
  4. Message-ID: <1993Jan22.013939.10269@cs.aukuni.ac.nz>
  5. From: jwil1@cs.aukuni.ac.nz (TMOTA)
  6. Date: Fri, 22 Jan 1993 01:39:39 GMT
  7. Sender: jwil1@cs.aukuni.ac.nz (TMOTA)
  8. Organization: Computer Science Dept. University of Auckland
  9. Lines: 75
  10.  
  11. > Or what if the user wants to use ChangeFSI instead of Translator (for reasons
  12.  
  13. >This is like saying you might want to use StrongEd rather than Edit to edit a
  14. >text file ... you arrange the RunType to point to the one you want, or be
  15. >prepared to load it by hand first.
  16.  
  17. No. It isn't quite the same. Edit vs StrongEd is generally a permanent choice,
  18. i.e. I run StrongEd all the time, and edit gets run only about 2 times a
  19. month, for about 30 seconds, to do something quick in a task window - I
  20. then save the text output of the taskwindow to StrongEd and quit Edit.
  21.  
  22. What I meant is, imagine you have 30 'alien format' pictures, and you want to
  23. load them all into Paint. However, *some* of them you want to run through
  24. ChangeFSI, and some through Translator.
  25.  
  26. If an arbitrary translator is auto-run when you drag the files to Paint,
  27. then you have no idea if the right choice of translator was made until it's
  28. too late.
  29.  
  30. And what if your default translation settings are not correct - the
  31. translator (possibly the wrong one) will be auto-loaded, and then proceed
  32. to give a totally wrong translation anyway.
  33.  
  34. In these cases, the user has to choose a translator by running it, set any
  35. translation options they desire, and *then* drag the files to Paint.
  36.  
  37. However, after some email chats, I have come to the conclusion that translation
  38. can best be handled by a module to which all translators register, and this
  39. can then orchestrate the collaboration between two or more applications to
  40. translate data automatically. Having this module provide a *command for
  41. translators to include in their !Run file would allow all translators
  42. to register themselves not only for translations, but also for auto-running
  43. if no other translation path is already possible with loaded applications.
  44.  
  45. >> It is extremely likely that I will therefore wish to supply scaling factors,
  46. >> quality factors (like FS dither or no dither, etc), colour translations
  47. >> (e.g. force to greyscale), etc. before loading the file.
  48.  
  49. >Yes ... but a large part of this kind of system is to make it easy for naive
  50. >users, who just want a default option that works.
  51.  
  52. Sure. But the method suggested just sounds too hit and miss. If a translation
  53. isn't available then a system variable is used to auto-run a translator
  54. that might stand only a small chance of being suitable, and use default
  55. settings that are more often than not going to be totally wrong.
  56.  
  57. The suggestion of using a module to control all of this
  58.   a) Makes everything more coherent. Somebody *knows* what is going on, rather
  59.      than applications making inspired guesses about the best course of action.
  60.  
  61.      This will make the protocol faster, as well as allowing the 'best'
  62.      translation out of a set of choices to be automatically chosen (in the
  63.      case of several translation steps between the source and destination
  64.      file formats)
  65.  
  66.      Also, it allows the possibility of giving the more advanced user a list
  67.      of possible translations and options and allow them to set things up
  68.      exactly as they want them before OKing the operation.
  69.  
  70.   b) Moves a lot of the effort from each application/writer into the master
  71.      module, so implementing the protocol from an editor/translator will be
  72.      much much simpler.
  73.  
  74. >Indeed ... but I don't think you should ever worry about making life a bit
  75. >harder for a programmer, if you make it easier for the user.
  76.  
  77. Sure, but only lazy sods like myself ever seem to be able to come up with
  78. easier ways of achieveing the same (or better) effect. If you won't even
  79. consider ease-of-programming in your plans, then you may just miss something
  80. crucial. Also, I think if any protocol is to find support, it has to be
  81. as easy as possible for the programmers to implement support for it, or
  82. it'll just fade away, and that benefits nobody.
  83.  
  84. -- 
  85. themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons
  86.