|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||||
MBaseRef interface.
See:
Description
| Interface Summary | |
|---|---|
| CollectionStatus | |
| Inheritor.Reparser | |
| SlumbConstants | Simple class to contain constants used in the index. |
| TheoryCollection | Simple interface to provide Theory objects. |
| Class Summary | |
|---|---|
| ErrorReporter | |
| FileStringStorage | Simple placeholder to write streams to files and give them a key |
| IndexedCollectionStatus | Class to denote the current status of a collection such as the listing the files, their IDs, their modification dates, and theories. |
| Inheritor | A class that is responsible to operate the inheritance procedure which allows included items to obtain new children and attributes based on the parents. |
| SluMBaseRef | |
| SluMBaseRef.IteratorOfMBaseRefDeps | |
| SluMBaseRefForTesting | |
| SluMBaseXmlRpcServer | Server to be used for XML-RPC calls to SlumbIndex. |
| SluMBaseXmlRpcServer.ErrorLister | |
| SlumbConsole | |
| SlumbFeed | Class to load (or reload) OMDoc content into LuceneMBase. |
| SlumbIndex | A general purpose object to store the current access to a LuceneMBaseIndex. |
| SlumbStorage | |
This package contains an OMDoc storage-implementation
based on Lucene and satisfying the contract of the
MBaseRef interface.
Typical users of this class invoke the methods of
MBaseRef to obtain the
parsed JDOM objects and other properties representing the content of each
of the OMDoc items.
SLuMB stands for serial-lucene-mbase and is the maturation
following several other content-storage implementations:
OmdocLuceneMBaseRef,
OmdocJdomMBase...
SLuMB, compared to LuceneMBase it is expected to implement imports
more correctly, to reload fast, and to scale up to big volumes.
SLuMB operates on content-collections stored in directories;
the collections are declared by properties of the form
mbaseRef.collections.xxx.rootDir, typically
inscribed in content-descriptors. The other properties
of the collection are read directly from the ContentDescr_*
properties file.
When ActiveMath starts, the Manager attempts
to start the MBaseRef implementation;
if the SluMBaseRef is chosen
(by the value of mbaseRef.class), its instantiation constructs
a SlumbIndex with the same parameters.
Once this instatiation is finished, the org.activemath.omdocjdom.SluMBaseRef
is ready to serve content.
The objective of the content-storage is to serve as interface between the content created by the authors and the other components of the ActiveMath learning environment. These components are expected to handle content-items individually without knowledge of their original context, hence a decontextualization is performed by the content-storage which includes:
imports elements).See the thesis of Paul Libbrecht (in progress) for a more explanatory description of the functions of the content-storage (in chapter 5) and metadata inheritance (in chapter 9).
Normal remote clients should use OJXmlRpcMBaseRef
to talk to the two normal servers that SLuMB responds to in an ActiveMath server.
mbaseRef.server.port (default 27000)
where it runs the SluMBaseXmlRpcServer.
The URL is then http://host:27000/.XmlrpcManager relays XML-RPC calls to the URL
http://host:8080/ActiveMath2/xmlrpc/mbase to SluMBaseXmlRpcServer.
This URL has the advantage of passing through proxies, so that if your ActiveMath is at
http://blip.de/, its MBase is accessible at
http://blip.de/ActiveMath2/xmlrpc/mbase.
Finally, a browser-based tool is available under http://host/ActiveMath2/tools/mbaseRef.cmd
that allows authors to see individual content-items, to browse collections' content and
to request reload. If configured (by the mbaseRef.collections.*.exec-before-reload properties),
this may request an update from a versioning server.
SluMBaseRef uses two indices for better
performance both managed by the
SlumbStorage: the small-index contains
the structural information (simple properties (item-type, metadata properties, titles)
and relationships) while the mass-index contains (references to) complete fragments
of XML (e.g. for MBaseRef.getChildren(org.activemath.abstractcontent.MBaseID, java.lang.String)).
Documents of the small-index are cheap to load fully in memory, documents
of the mass-index should only be loaded as streams, for example to build a JDOM
element or to serve over XML-RPC. Currently, the mass-storage is storing a file
for each fragment as done by the FileStringStorage.
SluMBaseRef's methods all compose a
Lucene Query and receive the
Document from which they extract the necessary
part of extract one of the mass-fields.
As per the WYCIWYG cycle, the reload operation is a fundamental aspect of
a regular authoring activity and it needs to be fast. Pilotted by the
SlumbFeed
class, SLuMB reloads (and loads) along the following process whose steps
are applied through all the collections configured to load:
Theory objects.Inheritor).
Each of the fragment of information relevant to this item
is stored in the small- or mass-index
The reload process uses data objects to perform its operations,
this includes CollectionStatus,
OMDocFile,
SlumbElt,
and Theory.
Moreover, the complete processing of OMDoc files is ensured by the JDOM
subclasses of the package org.activemath.omdocjdom which contains
the facilities to parse the OMDoc objects and, in particular, to resolve IDs
using the ID class.
One of the central roles of any content storage for authors is that
of offering services to ensure error-free content. As of this writing
reports reference
errors. It does so by the usage of the
OJSAXBuilder.LocationInfo.
Any component involved in the reload process, currently the data-objects,
report errors to the ErrorReporter.
whose static method ErrorReporter.getCurrentOrDumbReporter()
allows to obtain the instance of the currently running reload hence
to have the error-reporting reach its target, for example an authoring tool
requesting the reload.
|
||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | |||||||||