[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: External Site Mirroring & Indexing - Delegation ConditionallyAccepted (fwd)
my comments are in-line.
On Mon, 29 Nov 1999, Jason Pincin wrote:
> I'm gonna cc to the list, my PS comments on this topic:
>
> Here they are:
> __________________________________________
>
> A few entries in the requirments document, primarily #5 and #9, talk
> about the need to differentiate between internal "articles" and
> externally retrieved documents. It mentions the use of possibly a
> "Mirrored Links" table, etc. Before we go much further with this, I
> want to make my original expectations clear.
>
> The table "ExternalLinks" was intened to maintain URLS to ANY
> documentation not originated within the LKB. This includes ANY
> material on our own servers aquired by the process of mirroring. The
> DB doesn't care where it's at. If there's two different LDP documents,
> one on our server and one that's not - they both get entered into
> "ExternalLinks" as to there URL. Then, these are tied in with our
> organizational tree "KBObjects" by ObjectType #7 (External Link). They
> are accessed in the exact same manner as any other object i.e.
> /render.php3?op=1.5.9.38&oid=38&type=7&... but as an external link
> object, it will have a property of LinkURL or whatever it's called
> (it's documented with the API) - and it will be up to the display
> script to display the content inline formatted in some way consistant
> with out site.
>
> As I said - these were my original intents, and it's quite possible
> that people wish this to change.
Here's my opinion:
- Locally mirrored, external documentation should be displayed inline
(with LKB headers, sidebars, footers, etc) This content is fully indexed
by htdig and is linked off of the main index/categories pages. The
content exists under the /mirrors URL, but a sub-process (PHP or modperl)
reads the file and inserts it into the page dynamically.
- Remote content which we don't host is done via http-redirects, not
indexed by htdig, and is linked off of internal/mirrored documents as
"additional reading".
Why? Well mostly it has to to with technical reasons. First htdig wasn't
designed to be a internet search engine. But the real issue is how do you
display a remote URL inline? Well you can use frames (which the core
group has voted down repeatidly) which causes problems for htdig or you
can spawn a sub-process to grab the URL for the web client, process it,
and insert it into the page. This is fine for local URL's (which can be
accessed reliably and very fast), but this will kill our web server as
httpd sits idle for long periods of time while we download the remote page
(which may be on a down/slow server).
> I do whole heartedly agree with everything else on the requirments
> document, including the complete web based maintenance, support for
> CmdSchedule, etc. We need to discuss the ability to "differentiate"
> and how that will happen more though I presume.
So with that in mind, I suggest a new Object Type and a new table called
OffSiteLinks to hold these non-mirrored external docs. The only real
issue is should these off-site links be in the main index or only linked
off other inhouse/mirrored documents. I prefer the second.
> In the future, this
> will become one of the biggest deals of the site, as others begin to
> incorporate XML metadata, etc. Eventually it will be much more that
DocBook. Everyone is moving to DocBook. The LDP has recently distanced
themselves from LinuxDoc for DocBook, and DocBook is being used by the
OSWG. These two groups will be the major source of quality docs IMHO.
> Internal/External Documentation. Eventually we'll maintain the
> knowledge of wether it's a KB Support Article, a User's Manual, an
> INstallation HOWTO, etc. So we want to keep this future in mind as we
> design the current system...
Sounds like a Xref table that the different article tables
(internal/external) can reference. I Think this would be a great
feature. Imagine each article having a "type" associated with it telling
the user if it's a Short HowTo, Long HowTo, Manual, Man Page, etc.
> ______________________________________________ End of comments as seen
> on PS
>
>
> On Mon, Nov 29, 1999 at 08:49:49AM -0500, Daniel E. Markle wrote:
> > On Sat, Nov 27, 1999 at 03:19:54PM -0800, Aaron Turner wrote:
> > > The KB is a place for direct answers (such as the Microsoft KB is), not for
> > > docs.
> >
> > I agree with this and disagree, I believe the knowledge base needs to consist
> > of direct answers, but I also believe that external docs are often the best
> > source to answer some questions. In other words, we need both, not just one
> > or the other IMHO.
> >
> > --
> > -------------------
> > Daniel E. Markle
> > syntax@ashtech.net
> > http://www.ashtech.net/syntax
> > -------------------
>
> --
> Jason
> http://vodka.linuxkb.org/~chardros
>
--
Aaron Turner, Core Developer http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization http://linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net