home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / infosyst / gopher / 1266 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  3.9 KB
  1. Path: sparky!uunet!spool.mu.edu!umn.edu!news2.cis.umn.edu!gopher-news-daemon@boombox.micro.umn.edu
  2. Date: Thu, 19 Nov 92 18:48:09 PST
  3. From: barries@nye.nscee.edu (Fred Barrie)
  4. Message-ID: <9211200248.AA24641@nscee.edu>
  5. Original-To: gopher-news@boombox.micro.umn.edu
  6. Subject: Status report on Veronica development.
  7. Newsgroups: comp.infosystems.gopher
  8. Distribution: comp
  9. Sender: news@news2.cis.umn.edu
  10. Approved: comp.infosystems.gopher@news.cis.umn.edu
  11. Lines: 87
  12.  
  13.  
  14. Status report on Veronica development.     11-19-92
  15.  
  16. 1.    Imminenent enhancements to Veronica:
  17.  
  18.     A.    Veronica should return one and only one reference to each 
  19.         distinct item on the Net.  We are experimenting with several 
  20.         approaches and will implement a trial of at least one method,
  21.         in the next few days.
  22.  
  23.         The Veronica database will be rebuilt to give faster accesses
  24.         with the redundancy-removing algorithm.
  25.  
  26. 2.    Preliminary thoughts on proliferation of Veronica servers.
  27.  
  28.     A.    Each organization possessing several gopher servers should
  29.         be encouraged to run a site-wide Veronica service for those
  30.         gopher servers.
  31.  
  32.     B.    There should be "several" Veronica servers which index all
  33.         of gopherspace, possibly excepting the most transient data
  34.         ( see C below ).   Thusfar, our little NeXT Veronica at 
  35.         Nevada has not crashed under the load  ( typical "load"
  36.         between 3 and 8 ).  But it's response is far from fast enough.
  37.         These large Veronicas need faster hardware.
  38.  
  39.     C.    Specialized Veronica servers for transient data.  USENET
  40.         offerings in particular need not be indexed and reindexed
  41.         by all the Veronica servers.  We have found it difficult to 
  42.         automatically filter USENET news directories and to 
  43.         eliminate redundant presentation of USENET items.  Total 
  44.         Veronica loads could be reduced by implementing specialized
  45.         Veronica servers for such transient data.
  46.  
  47.     D.    Some Veronica servers could specialize by topics.  This could 
  48.         be implemented easily if these servers got the relevant 
  49.         data by ftp from the 'large' Veronicas of B. above.
  50.         We think it would be much more effective to acquire the data
  51.         from the large servers, rather than propagating 100s of
  52.         gopherwalks all over the net.
  53.  
  54.         In general we are wary of this proposal.  The utility of 
  55.         Veronica derives from its ability to index "everything".
  56.         Topic subdivision is only as good as the keyword scheme.
  57.         We think those schemes are never very good.  It is much 
  58.         better to have a fast index of "everything" than to have
  59.         a very fast index that has been subjected to someone else's
  60.         preconceived categories.
  61.  
  62.         Several early commentators have suggested that topical
  63.         division are important to Veronica's utility.  Most of
  64.         these comments objected to a volume of seemingly irrelevant
  65.         items returned by the searches.  We think this volume will
  66.         be much reduced when we elimate duplicate items.  Further,
  67.         we think that much of the annoyance was caused by WAITING
  68.         for duplicate and seemingly-irrelevant items.  We think
  69.         that faster searches without redundant items can satisfy
  70.         most users while still indexing "everything".
  71.  
  72.         We recognize that we may repent this opinion if (when) the
  73.         volume of gopherspace explodes.   
  74.  
  75.         Meanwhile, we suggest that the following additions to 
  76.         the gopher+ spec could make Veronica more efficient. 
  77.  
  78.  
  79. 3.    Suggested additions to gopher+ protocol.
  80.     Add some information to the new gopher-item fields.  
  81.  
  82.     A.    An "indexing" field ( boolean ) could be added, perhaps
  83.         to the ADMIN block.  A Veronica could ignore items so marked,
  84.         such as News directories.
  85.  
  86.     B.    A "subject=" field could be added.  This would rationalize
  87.         the topic-oriented searches discussed in 2-D above.
  88.         "Subject" must take multiple values.  We recognize that this
  89.         is a watered-down ABSTRACT.
  90.         
  91.         Items lacking a "subject" field would inherit "subject"
  92.         from their parent.
  93.  
  94.     C.    A boolean "local" field.   This would help prune the 
  95.         duplicate references.
  96.         
  97.  
  98. Fred Barrie, Steve Foster
  99. University of Nevada
  100.