Table of contents
- 1. Section A
- 1.1. Section A.1
- 2. Section B
Topics requested:
- Ability to control Page Templates layout
- One can create very sophisticated Templates, even store situational apps or dynamic reports in the template namespace. from the editor this is only a click away. Live Content Demo: ./CNN_story and then CNN Top Story.
- Contribute content via page templates/ forms
- Easy to do, every wiki page is it's own REST based XML web-service. HTTP verbs to operate. E.g.- ABB. API Reference.
- Easy to do, every wiki page is it's own REST based XML web-service. HTTP verbs to operate. E.g.- ABB. API Reference.
- Ability for users to edit content on a component within a page without having to edit the entire the page i.e., component level/Section Level Editing
- See Page Transclusions or just edit the sections below.
- See Page Transclusions or just edit the sections below.
- Ability to control parent-child relationships.
- Add subpages, multi-page templates, move pages on the fly, use desktop connector to reorg.
- Add subpages, multi-page templates, move pages on the fly, use desktop connector to reorg.
- Page component rendering as accordion and tabs.
- Simply add an extension. Look at MindTouch Press Room for example
- Simply add an extension. Look at MindTouch Press Room for example
- Provide users with ability to edit pages only within Rich Text Edit
- Rich text is default, note no wikitext, everything is XHTML. This makes for a superior editing experience because wikitext editors are really bad in comparison to HTML editors. Also, this makes data portable and copy/paste from other files or websites much more polished.
- Ability to create a navigable category structure
- See DekiScript sample
- See DekiScript sample
- Browse by Tags
- Search
- lucene, indexes all file attachments, very robust, backed by Apache Foundation.
- lucene, indexes all file attachments, very robust, backed by Apache Foundation.
- Aggregation of content from blogs, discussion forums. social bookmarks, etc. based on a tag
- See above top story example or SoCal Fires
| Lorem ipsum blah blah sfcsad sadca asdcsa | Lorem ipsu sad as das dasm blah blah |
Section A
MindTouch Deki Wiki's architecture is dramatically different from traditional software applications. To explain this, let's compare it to how most software is architected. Traditional software applications are developed in a monolithic fashion. For example, when a web application is developed it looks like the image shown in Figure 1.
Figure 1 - Traditional Software Architecture
The application in Figure 1 is built in a specific programming language and requires a specific operating system. When an engineer needs to extend the application, the engineer must use the same programming language as the original implementer to create new extensions and these must be installed locally on the same operating system. In short, extending applications requires the engineer to build inside the same monolithic environment using the same components that the application uses, regardless of the toolset the engineer is already familiar with. Furthermore, integrating other systems and services is unnecessarily difficult because it requires a deep understanding of the monolith, similar styles and disciplines in engineering, and if a break is introduced to the stack, the entire monolith can be rendered inoperable.
Section A.1
This monolithic approach to software development has not changed in decades. In today's connected world, this model does not lend itself to capturing the capabilities of applications that live inherently in the network. It is inefficient because even when an application has a network accessible API -- and most don't -- it only behaves as an end point, a behavioral silo limited to the confines of its own monolithic architecture. These point applications are incapable of realizing the latent benefits of the network fabric that exist in organizations and across the world. When the application exists in the network instead, many desirous effects are realized, including improved scaling, ease of extensibility, ease of integration, incremental development costs, better use of engineering resources, and more...
Section B
MindTouch takes a very different approach to software development.
Figure 2 - Deki Wiki: A Distributed Heterogeneous System
Figure 2 provides a graphical depiction of MindTouch Deki Wiki's software architecture. Deki Wiki is a composition of loosely coupled heterogeneous services that exist across networks. They share their behavior in a distributed and concurrent manner through the Deki Wiki API and Dream (Dream is omitted for simplicity, see Figure 3). New functionality can be added in any programming language on any operating system executing on any server that communicates over any web protocol. In short, the application lives in the network. Rather than requiring adherence to a particular interface in a particular language, such as Java or C#, extensions only require adherence to a stateless web protocol. In essence, this is the wire implementation and the benefits are far reaching.
Let's take a more detailed look at the architecture of Deki Wiki.
Figure 3 - Detailed view of Deki Wiki's architecture
As mentioned earlier, Deki Wiki is a wiki interface to a distributed application platform. Note the red box labeled "wiki interface". This is the user-interface client that communicates to the Deki Wiki API (red box) over HTTP/S. The Deki Wiki API uses Dream (yellow box) to federate and orchestrate functionality from other services, applications, and data stores, enabling Deki Wiki to be used as an information bus across all of them. In essence, MindTouch Deki Wiki is the connective tissue within the enterprise.
- Tag page
- What links here
Files 1
| File | Size | Date | Attached by | |||
|---|---|---|---|---|---|---|
 | | documentation task team first meeting.doc No description | 56 kB | 19:29, 29 Apr 2008 | AaronF | Actions |
Images 2
