121 lines
5.3 KiB

Hopefully this gives you a general idea of how ScrollServer works. You'll have
to read up on ScrollKeeper as well to understand how the two work together.
If you would like to help develop ScrollServer, there are some bugs listed on
the SourceForge project page you could look into, or write me if you want to
develop a new feature. Most of the current SourceForge bugs are really features
and other enhancements. I have a zero bug policy. My policy is to always fix
bugs before developing any features.
If you are interested in coding C, then ScrollKeeper would appreciate your
help and deserves your support.
ScrollServer and ScrollKeeper have the potential to become a complete
distributed information database based on the latest XML technologies for
creating richly linked data. There are some large hurdles to that
accomplishment, particularly the fact that these technologies are relatively new
and so ScrollServer is on the cutting edge. But that is where the fun is.
It is only recently that Linux documentation has started to move seriously into
XML, allowing projects such as this to exist. Thanks to all the hard work people
have put into creating good documentation for Linux. Hopefully ScrollServer will
make it easier than ever to share and access that documentation.
XML Standards
One goal of ScrollServer is to provide a completely standards-based
implementation to further the use of standards on the network. It is built using
the most recent W3C recommendations. Please read them if you want to hack any of
these technologies:
DocBook 4.1
OMF (Opensource Meta-data Framework, based on Dublin Core)
RDF (W3C Recommendation)
XMLBase (W3C Recommendation)
XLink (W3C Recommendation)
XPointer (W3C Last Call Working Draft)
XML Topic Maps
Server Process
The server process is entirely in Python and makes use of the xml libraries.
All html files are generated using xsl stylesheets (XSLT) and formatting is
performed with a css stylesheet. There is a single stylesheet right now, but I
want to allow the user to select the stylesheet they prefer. The HTTP server is
based on BaseHTTPServer.
The server process in ScrollServer will also be a client process, performing
document discovery in remote ScrollServers, essentially merging the contents of
your local ScrollKeeper database with those located on remote machines and
allowing your document collection to be shared with others. You could publish a
single document, if you author a HOWTO, or you could publish an entire
collection like the LDP.
Document Processing
Internal pages are generated from xsl stylesheets. The documentation itself is
generated from DocBook SGML and XML sources and xsl stylesheets, but eventually
it will support man pages, info pages, and other formats.
Documents in html are served, but they look different from the DocBook documents
because we don't generate them ourselves. There is no navigation bar on the top,
for example, and they don't use my stylesheets. There is a bit of ad-hackery
involved in serving documents that are physically distributed through a common
uri scheme so they appear to be part of a single tree.
There is no support for processing documents that are stored remotely. That's a
good todo item for somebody. It's pretty trivial using urllib. Unfortunately,
ScrollKeeper doesn't yet support them.
There is currently no search functionality. I could use one of the existing html
searching engines, and might have to to support html sources, but more powerful
searching should be possible someday using a DocBook aware search engine.
A huge problem in all help systems is finding the needle in the haystack that
will answer your problem. So, the search engine has to have a big focus to make
ScrollServer an indispensable tool on your desktop.
I want to look into using XQuery for remote document queries, but it is a new
proposal and so it is changing rapidly. Perhaps it is best to put that off for
a bit until it stabilizes. RDF might be part of a good solution.
Other Possibilities
Just about any other web based service you can imagine could be implemented and
integrated into ScrollServer, including message boards on the various topics.
XLink provides for creating links from document A to document B from within
Document C, along with many other powerful ways of associating data. A user
could conceivably write a `post-it' style notee on their document, and share
that note with other readers of the document, where it could be accepted or
rejected or edited by others. There are many other possibilities as well.
It could be possible to even implement something aking to Wiki functionality,
allowing readers of some online documents to edit them and share their
If I decide to go with a URN based scheme for these additional services, they
could even be implemented as plugins.
Who knows how much of this will ever really happen. It all depends on interest
and help from others. But I hope you get the idea that eventually I want to see
ScrollServer provide higher level capabilities than your standard help browser.
I'd like to implement the concepts and technologies in what is called the
`Semantic Net'. Someday, when the web is XML based, ScrollServer will be in a
really good place to take advantage of it.