|PREV NEXT||FRAMES NO FRAMES|
|com.glaforge.i18n.io||Third-party code for determining the text encoding of files.|
|org.xiruss||Top-level classes for the XIRUSS repository HTTP API server.|
|org.xiruss.demos.simpleui||Provides a simple graphical user interface for interacting with a XIRUSS repository.|
|org.xiruss.repository||Defines the base interfaces and implementation classes for XIRUSS repository servers and clients.|
|org.xiruss.repository.api||Defines the repository-level interfaces common to clients and servers.|
|org.xiruss.repository.client.importers||Provides classes that support importing data objects into the repository.|
|org.xiruss.repository.client.importers.linkmanagement||Classes that support the creation of "referent tracking documents" used to manage element-to-element links via the SnapCM dependency mechanism.|
|org.xiruss.repository.client.importers.xml||Provides classes for supporting the import of generic XML documents as well as XSD schemas and XSLT style sheets.|
|org.xiruss.repository.common||Holds implementation classes usable by both clients and servers.|
|org.xiruss.repository.multiuser.api||Defines APIs for multi-user repositories.|
|org.xiruss.repository.multiuser.server||Server-side implementation classes for multi-user server objects.|
|org.xiruss.repository.multiuserschema_aware||API for schema-aware repositories.|
|org.xiruss.repository.schema_aware||Server-side base implementation of a multi-user, schema-aware repository.|
|org.xiruss.repository.schema_aware.api||API for schema-aware repositories.|
|org.xiruss.repository.server||Implementation classes for the core server-side objects that make up a SnapCM repository.|
|org.xiruss.repository.server.linkmanagement||Server-side base implementations of the link-management-specific interfaces.|
|org.xiruss.repository.server.reuse_support||Contains classes that support the management of use-by-reference relationships among versions.|
|org.xiruss.repository.server.schema_aware||Server-side base implementation of the schema-aware repository classes.|
|org.xiruss.repository.server.storagemanagement||Contains classes that manage the storage of Versions that are storage objects (that is, they contain data and act like files).|
|org.xiruss.repository.server.storagemanagement.specializations||Defines specializations of StorageObject that understand the details of specific kinds of data.|
|org.xiruss.snapcm||Defines the SnapCM API.|
|org.xiruss.snapcm.api||Defines the SnapCM API as a set of interfaces and exception types.|
|org.xiruss.snapcm.api.helpers||Defines types that are not part of the core SnapCM data model but that make working with SnapCM objects more convenient.|
|org.xiruss.util||Utility classes that are used by all parts of the code.|
|org.xiruss.util.xpointer||Support for processing and resolution of XPointers.|
|org.xiruss.xirussrepository.api||Defines the API for the XirussRepository.|
|org.xiruss.xirussrepository.client||This package provides client-side proxies that implement all the relevant Repository and XirussRepository APIs and manage all communication with the HTTP Xiruss Repository API (provided by the JettyXirussHttpApiRunner class.|
|org.xiruss.xirussrepository.server||Implementation of the XirussRepository API.|
|org.xiruss.xirussrepository.server.jetty||Implements the necessary Jetty-defined APIs, implementing a Jetty-based HTTP server that implements the Xiruss HTTP REST API.|
|org.xiruss.xirussrepository.server.jetty.apiserver||Implements the Xiruss HTTP API handler and repository-object-type specific Jetty Resources that manage the translation of specific Xiruss Repository objects into HTTP actions that result in XML API response messages (i.e., the data contents of a version or a list of resources or whatever.|
|org.xiruss.xirussrepository.server.jetty.viewer||Implements the Xiruss HTTP "viewer" server, that is the server that allows direct access to repository resources for "viewing", including access to version contents via a direct and obvious URL (i.e., the version ID in any conetext or resource ID within a snapshot context.|
The XIRUSS-T system is an educational and demonstration tool that has several primary goals:
The XIRUSS-T code has been implemented using the basic engineering principle of "make it work, make it right, make it fast, in that order". It has been implemented almost entirely using test-driven development and subsequent refactoring. I have also applied the eXtreme Programming principle of "the simplest thing that could possibly work" to the code. In addition, as a demonstration system, I have tried to make the code as direct and clear as possible, often at the expense of even obvious optimization techniques that experienced programmers might use simply by habit. Thus, while I'm reasonably sure that the behavior of the system is correct per the relevant specs or requirements, I cannot claim that the code as written represents the best implementation approach. This is to a large degree an ongoing experiment in CMS implementation by "simplest possible means". If you come across any code that offends you, please report it to me--I do not claim to be an expert programmer, in Java or any other language (except possible XSLT), and am always eager to learn. I have tried to apply fundamental design patterns where appropriate but you know how it goes.
All of this means in part that the XIRUSS-T system has not been optimized in any way for performance or scalability. It is explicitly a toy for demonstration and experimental purposes. A production-quality system that provided the same features would require a significant amount of additional engineering to make it fast, scalable, and reliable. By the same token, I have not done anything in particular to ensure proper support for concurrency or thread safety. XIRUSS-T as currently implemented is essentially a single-user system intended for non-stressful demonstrations. Any actual correct concurrency or multi-user behavior is accidental.
The XIRUSS-T system provides the following sets of features:
The current XIRUSS-T implementation does not yet have a set of export features. However, through the Web API any version can be accessed as a URL-addressible resource. XML documents have all their HTTP-based pointers rewritten on import to point to the corresponding target as it exists in the repository. This means that normal XML applications that do URL resolution (which should be all normal XML applications) can simply operate on XIRUSS-managed documents for read purposes without any further integration with XIRUSS. For example, you can point an XSLT processor at a XIRUSS-managed XML document by URL and it should just work. (And XIRUSS-T comes with a built-in XSLT importer so the style sheet itself can also be managed in XIRUSS.)
This means that, for the simple use case of read-only access to compound documents, as long as there is a Web connection to the XIRUSS repository, there is no need for an explicit export action.
In addition, the existence of support for direct HTTP PUT of new versions means that editors and other data writing applications can integrate with XIRUSS simply by constructing an HTTP PUT request, along with any HTTP POST requests needed (for example, to create a new mutable snapshot or to set specific properties on a version).
This all means that there is less need for a full export framework merely in order to enable read-only or read-write integration with the repository.
So I haven't done it yet. Export is a relatively low priority relative to other useful features, such as nice HTTP-based importer applications, better out-of-the box Web pages for the repository, and so on.
The best way to start understanding how this code works and how it is intended to be used is to look at the unit tests.
The top-level tests XirussRepositoryTest and JettyServerTest show how to interact with the XIRUSS system from the client perspective, that is, how to put things into the repository and get them back out again. This is the best place to start.
The importer tests (xiruss.importers) show how to use the import framework to do importing of files and documents into the XIRUSS system.
The SnapCM semantics are demonstrated and tested through the xiruss.snapcm tests.
See the description for a specific package for more details about what that package does and the design approach behind the code in that package.
|PREV NEXT||FRAMES NO FRAMES|