home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / gopher / 1020 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.4 KB
  1. Path: sparky!uunet!think.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!bionet!raven.alaska.edu!news.u.washington.edu!nntp.uoregon.edu!jqj
  2. From: jqj@nntp.uoregon.edu (JQ Johnson)
  3. Newsgroups: alt.gopher
  4. Subject: Re: Whois/finger patch for Unix client
  5. Message-ID: <1992Jul21.151330.27447@nntp.uoregon.edu>
  6. Date: 21 Jul 92 15:13:30 GMT
  7. References: <BrHzyC.8ID@usenet.ucs.indiana.edu> <19920717180944SEB1525@MVS.draper.com>
  8. Organization: University of Oregon Network Services
  9. Lines: 37
  10.  
  11. Any new extension mechanism for gopher should do more than the present
  12. "add a new type" mechanism.  I see the major current problem with the
  13. protocol being an overloading of the semantics of the type character.
  14. Currently, it is used to distinguish:
  15.   -    different kinds of object on a server (e.g. different file
  16.     content types)
  17.   -    different network interaction protocols (e.g. menu based file
  18.     retrieval, telnet, etc.)
  19.   -    [if the Schemers approach is widely adopted] different
  20.     argument parsing protocols i.e. different interpretations of
  21.     the selector line
  22.   -    etc.
  23.  
  24. I see these as largely orthogonal.  For example, I can imagine wanting
  25. string RPC arguments [the RS protocol] for any 0-like or 1-like gopher
  26. type, but I note that they are not very relevant to the telnet type.
  27. I can imagine a different style of argument processing also being
  28. desired, again applying to any type of returned object.  And so on.
  29.  
  30. Bottom line:  a protocol extension mechanism should satisfy new needs.
  31. Unfortunately, I'm not convinced we know yet what those new needs are.
  32.  
  33. P.S.: we do have SOME ideas of the new needs.  It's clear that many
  34. people want more attributes/properties available for file-like
  35. objects, e.g. creator, who to contact, etc (the Brown proposal).
  36. It's clear that a more powerful alternation mechanism than the present
  37. "+" type is desirable to allow clients to select their preferred
  38. representation of equivalent data.  It's clear that the present
  39. single-character filetype space is too small.  It's clear we need to
  40. continue to think about scripting and such.  It may be that some type
  41. of authentication mechanism is needed.  And so on.  The real challenge
  42. may be to build extensions that preserve protocol purity and simplicity.
  43. -- 
  44. JQ Johnson
  45. Director of Network Services        Office: 250E Computing Center
  46. Computing Center            Internet: jqj@ns.uoregon.edu
  47. University of Oregon            voice:    (503) 346-1746
  48.