Re: Open Document Environment (ODE)

[Aaron Turner <aturner@linuxkb.org>]

On Sun, 9 Jan 2000 dave@lafn.org wrote:

> On Sun, Jan 09, 2000 at 01:05:21AM -0800, Aaron Turner wrote:
> > 
> > 0) I think a global mailing list for those projects interested in this is
> > in order.  I know I'll subscribe.  I'm sure I can get Roger from SEUL to
> > sponsor the list on his mail server unless someone feels strongly another
> > way.  odo@seul.org perhaps?  Or lodo for Linux Open Doc Org.?  
> > 
> Since it's a goal of LDP to integrate all Linux Documentation, I would
> like to see LDP as the lead organization for this.  We've had a few 
> people working on this (or parts of it): David Wheeler, Peter Elliot,
> and Paul Jones.

While I don't really care where the list has a home, I do want to point
out that there are other projects other than just the LDP which have this
concept as a goal.  I do respect the LDP and what it has done for the
Linux community, but I'm also concerned that one organization is given too
much power because we all have different views and beliefs about how
things should be done.  A counsel where each organization has an equal
voice IMHO is better than one organization leading the effort.  Also,
having the LDP or other Linux centric group as the LKBP heading this may
make it harder to bring in talent from other OS's like FreeBSD.
 
> > 1) Having one specific format (Docbook for example) is great from an
> > indexing and searching perspective. 
> 
> Another problem with Docbook concerns people that use old PCs.
> Docbook is slow to compile and uses a lot of memory/disk space.

yep.  However this is only an issue if you store the data locally, which
of course creates other tradeoffs.

> > Complicated analogies which have color coded sections and things like that
> > are confusing, 
> 
> Another reason for not using color is that some people still use monochrome
> terminals/monitors.

Fewer and fewer people are limited to only monochrome monitors, but it is
a consideration never the less.  One issue that I'm sure we'll run into
time and time again is balancing advanced features which help most users
with locking a small group out because they can't take advantage of those
features.

> > 7a) Local/LAN/WAN retrieval is going to be hard.  To build a scalable
> > infrastructure like this is a huge effort.  
> 
> I don't understand this.  By local you must mean that the info is on
> your local PC.  Right now all major Linux distributions include the
> HOWTOs, Manual Pages, and GNU info docs and these get on local PC hard
> disks.  One can go to the HOWTO directory and use grep for searching
> all of the words (and phrases) in all of the HOWTOs.  This works
> better if the HOWTOs are in plain text format.  But then one has to
> repeat this in different directory trees for non-HOWTO docs.  One may
> search the Debian "Packages" file to find what software is freely
> available and this file contains a paragraph or two about what each
> package does.  Someone recently came out with a "whatfor" tool that
> tells you what each system file is used for.  Thus we now have methods
> of searching Linux documentation locally but it's very crude.  Should
> not all this be expanded and improved on?

Yes documentation exists locally but as you point out it has no
categorization and is difficult to find.  I don't beileve that we can in
the near future effectively build a system that properly addresses the
existing inadequacies of the current system for seemless local
documentation storage within a remote hierarchal storage cloud. 

Putting a bunch of files in a directory does not make a useable
documentation resource once the number of documents grows beyond a certain
limit (that limit being the number of lines a person is willing to read
looking for an answer).

To scale into the 100's of documents you must use more advanced means for
storing and retrieving the documentation.  The requirements for such a
system tend to prevent the avg. Joe from installing it for various reasons
(too hard to do, not enough disk space or RAM, etc).  For example the
backend of the Linux KB is currently about 10MB compressed of application
source code and scripts. This doesn't even include the docs yet.  We're
using Apache, Ht://Dig, mod_perl, PHP, MySQL and each one has to be
installed/configured in a certain way to make it work.

We're much better off building a centeralized repository as this is much
simpler to develop and maintain, becuase you don't want to try to help
everyone install this sort of thing on their system.  Yes, later on you
can make it easier and get the distros to include it on their CDROM, but
that's aways away.  

To put it in perspective, Microsoft doesn't include a copy of the
Microsoft Knowledge Base with every copy of NT or 98- I think there are a
number of vaild reasons why.

> [Regarding advanced information retrieval tools]
> > Realize that 99.99% of the people will never install it locally and 
> > probably about 98% will not install it on their LAN.  
> 
> Doesn't it depend on the effort needed to install it? 

Absolutely.  I guess I believe that this project is going to be database
(SQL or LDAP) driven.  That will lock out a lot of people from trying to
install it on their own.  I've tried doing it without a DB before and
found it extreemely inadequate in terms of scalability.

>  If it's easy to
> install and comes with most distributions then I would expect it to be
> used a lot.  It's true that you can have a better system on-line but
> there's the cost of more traffic on the internet.  This traffic cost
> is much less on a local system (LAN or PC-bus).  Both advanced on-line
> and simpler local info search systems are needed.

Ok, I can buy that last part.  Not sure how to pull it off, but it should
be doable.  However with the Internet moving in the way it is, the need
for local storage is becoming smaller not only just in the States, but in
most of the world as well.

> > 14) Document Browser should be a web browser initially. Once you start
> > requiring end users to install special software that has other
> > requirements (such as a viewer using the GTK or QT libraries), your
> > potential userbase shrinks.  Should be Lynx friendly.
> 
> A problem with html is that we would like to use free software
> browsers like Lynx.  But Lynx is too hard to learn.  At present, plain
> text is often the best choice since most people know how to deal with
> it.  For html there is a need for grep-like searches on sets of html
> files but we don't seem to have this.  Thus I suggest that in addition
> to browsing with an HTML browser, that plain text searching be also
> available.  In the vim editor one may find the next occurrence of a
> word by just having the cursor on it and hitting a certain key.  One
> can use this feature something like an html link (even thought it's
> plain text).

I guess I feel that Lynx is easier to learn than regular expressions or
vim.  You just use the arrow keys to navigate.  I think that this is one
of those cases where I believe that to have a certain level of
functionality for the user you have to expect something of the user.
Things like forms are indespensible for allowing the user to find what
they're looking for.

--
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
The difference between `Unstable' and `Usable' is only two characters: NT




--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org