Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #18827

Re: demise of sun.com

Show all headers | View raw

Martin Gregorie wrote:
> Roedy Green wrote:
>> There is a similar problem with RFCs.  Old ones don't have a link to the
>> new replacement.
>>
> 
> ...but there's a known solution for RFCs - the RFC search engine 
>    http://www.rfc-editor.org/rfcsearch.html 
> 
> This takes an RFC number or a word/phrase in the RFC title and digs out 
> the referenced RFC plus a chain linked forward and backward to show all 
> the RFCs your taget obsoleted as well as those that make it obsolete.
> 
>> The author of a deleted document could most easily set up a forward link
>> faster than even one user could research it.

Martin disproves this.

Google disproves this.

> Sure, but using the search engine is easier for both author and 
> researchers.
> 
> ... I now return you to the scheduled program.

Good search tools simulate intelligence better than cognitive 
algorithms do, under many circumstances.

http://xkcd.com/903/

Suppose you write seventeen articles a year online, "you" being 
any arbitrary entity such as you personally, a committee, a reporting 
system or whatnot. Say the articles have a half-life of interval until 
a link needs updating, along the lines that sun.com and RFC articles do.

You would need to review your own documents over years to keep them 
up to date. This is what Oracle has done. Given finite resources, 
there is a limit to how many articles you can update per year, and 
still maintain your output of new articles. It stands to reason that 
some articles will not be updated at any given time.

Regardless of the actual numbers, it's clear that link maintenance 
will require increasing energy over time, as the mass of articles grows.

Consider instead a search solution along the lines Martin mentioned 
for RFCs. Links can still be maintained, according to a triage system 
of need and benefit. But they need not be, given a search system that 
elicits the same connections on demand.

The search system complexity and deficiencies are completely independent 
of the article base, and presumably bounded. Instead of an increasing 
energy investment in link maintenance, lacking opportunity for innovation, 
you have steady energy investment in search enhancement, with ample 
opportunity for innovation and increased value.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

demise of sun.com Roedy Green <see_website@mindprod.com.invalid> - 2012-09-15 00:54 -0700
  Re: demise of sun.com Roedy Green <see_website@mindprod.com.invalid> - 2012-09-15 08:27 -0700
    Re: demise of sun.com Mark <i@dontgetlotsofspamanymore.invalid> - 2012-09-17 10:28 +0100
      Re: demise of sun.com "John B. Matthews" <nospam@nospam.invalid> - 2012-09-17 06:51 -0400
        Re: demise of sun.com Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-17 10:40 -0700
          Re: demise of sun.com Arne Vajhøj <arne@vajhoej.dk> - 2012-09-17 17:39 -0400
    Re: demise of sun.com Roedy Green <see_website@mindprod.com.invalid> - 2012-09-18 04:27 -0700
      Re: demise of sun.com Martin Gregorie <martin@address-in-sig.invalid> - 2012-09-18 19:41 +0000
        Re: demise of sun.com Lew <lewbloch@gmail.com> - 2012-09-18 13:21 -0700
          Re: demise of sun.com Martin Gregorie <martin@address-in-sig.invalid> - 2012-09-18 21:29 +0000
          Re: demise of sun.com Gunter Herrmann <notformail0106@earthlink.net> - 2012-09-19 13:30 -0400
      Re: demise of sun.com Stanimir Stamenkov <s7an10@netscape.net> - 2012-09-19 00:42 +0300

csiph-web