Having now considered CMS products, and gotten our hands fairly dirty in the conceptual differences, it is apparent that an encompassing solution will be necessary for a system such as initially conceived. Covering the total range of features that has been implemented across CMS systems is beyond the scope of the present version of this document. We shall look at those features discussed thus far, and a few extra features present in many systems.
When considering features we shall look at them in their relationship to a component architecture, such as implemented in Zope. Since we are in the process of [re]defining a solution, we will illustrate what level of system design would be necessary for a feature's inclusion, and what stage in the process implementation would occur.
| Feature | Component Level |
Stage for Inclusion |
Comments |
| Slash Newsfeed | Adapter | 1 | These features form much of the basis for peoples' interaction. it is a good conveyance of the Component model to note that each of these features would be implemented as an adapter, which view and interact with a single service (as mentioned earlier). Archiving would be the most static of these views, though would still be an adapter. Comparatively, chat is so dynamic that implementing it in a web browser would be tricky. Syndication feeds would be adapters of a largely read-only nature. |
| Forum / Discussion / Mailing list | Adapter | 1 | |
| Wiki | Adapter | 1 | |
| Journal / Blog | Adapter | 1 | |
| Archive | Adapter | 1 | |
| Gallery | Adapter | 1 | |
| Polls / Surveys | Adapter | 1 | |
| Chat | Adapter | 3 | |
| Syndication / RSS / Atoms | Adapter | 2 | |
| Notebook | Service | 3 | These features would require a well-designed inter-component interface, as much of their work would occur in coordinating with other components. The contact manager and mail reader, in particular, could draw their information from remote sources - and in the case of mail could be used to remotely interact with the system (post messages, request information, etc.) |
| Calendar | Service | 2 | |
| Directory | Service | 3 | |
| Contact Management | Service | 3 | |
| Mail Reader | Service | 3 | |
| Guestbook | Service | 2 | |
| Templates (overall site layout) | Presentation | 1 | Most of these features focus on the display of existing content in the system, and would use various arrangements of Views, Resources, Skins, Layers (as defined within Zope). User account capabilities would be managed as a service accessed by other components through an object-to-object interface. Search in its most basic form is a presentation component, but it may take the role of a hybrid service / adapter as it becomes an integral element in the presentation of customized views. |
| My Page / Dashboard / RSS Boxes | Presentation | 1 | |
| Search | Presentation | 1 | |
| Themes / Skins | Presentation | 1 | |
| User Accounts | Service | 1 | |
| Administrative Interface | Adapter | 1 | Administration is performed through adapters into other services, and some presentation components. A 'help desk' area would be a service that would act a recording and reporting body for other components. FAQ pages would result from solved user problems, and would be an adapter of the help desk service. |
| Help Desk / Bug Reporting | Service | 2 | |
| FAQ / Overview | Adapter | 2 | |
| Data Import | Adapter | 2 | Versioning is likely to be a utility since it is background to the active tasks that are being labeled with versions. It's close connection with other components may see it have a more blurred definition, in time. All other features in this section essentially deal with the handling of data, and thus will be robust adapters to existing data services. |
| File up / down / management | Adapter | 2 | |
| Visualization | Adapter | 3 | |
| Versioning | Service | 2 | |
| Client-side applications | Adapter | 4 | These features represent connection to the system from external programs or services. As such most of them will require adapters for these external programs to automatically interface with the system. Though this includes mobile device access, the feature is primarily for human reading on small displays, thus a presentation component. |
| Server-side Applications | Adapter | 4 | |
| Mobile Access | Presentation | 4 | |
| Plug-in Design | Adapter | 1 | |
| Web Services(atoms, tags, API) | Adapter | 1 | |
| Scheduling & Staging of Content | Service | 3 | For chronological features to be available throughout the system in a uniform manner they will be implemented as services. Caching would be its own service as it is a critical function. It is conceivable that all chronological features, here and above, would be adapters of Ephemerides service. |
| Time Tracking | Service | 3 | |
| Cache Control | Service | 1 | |
| Grids | Service | 4 | These features would be accessed through major components in the forms of services that would be accessible in a variety of ways. In most scenarios people need not have any explicit awareness of their presence, and in some cases the user interface many not change at all. |
| P2P | Service | 4 |
In considering implementation it is important to note that the list above is far removed from a design document or schematic, and as such has omitted many components necessary to a functioning system. The stages of component development have been organized around the needs of a community, an organization, lightly coordinated research and then heavily coordinated research. To re-summarize the features above in terms of group needs:
An important matter is for early system versions to be able to engender the type of dialogue necessary for the system's own growth. Feedback integration of this sort is highly important - one of the first 'proofs of concept' to go through for systems that proposed to facilitate collaboration. Now lets gain a sense of the roadmap.
© New Alexandria 2002