You are not logged in Log in Join
You are here: Home » Members » klm » ZopeDiscussionModes » KenManheimer » wikipage_view

Log in
Name

Password

 
 
FrontPage » DiscussionsProponents »

KenManheimer

KenManheimer's ZopeDiscussionModes? Mission Page

mailto:[email protected]

I'm a developer with Zope Corporation, and have had a hand in a number of discussion-oriented collaboration tools while here, and before: an issue tracker , wiki enhancments , and work on the Mailman maillist manager. The overlap and the disconnects between these systems helps explain my overriding goal.

For each application, i wound up spending a lot of time developing a content type with unique features that i could not reuse across applications. I would like, and think it's quite possible, to instead package up the features for deployment in any content types - to have the ability to reuse the features, mix and match the behaviors of the specialized content types (presentation, structuring, organization, access protocols, and so on).

For instance, in my ideal world i would be able to create a piece of content concerning some issue to be solved, enable some supporters to take on the task in a structured workflow of my choice, enable low-impedence editing of the item, generation of new, related ones, and organization of the collection in a wiki-like fashion, enable web, ftp, webdav, nttp, and smtp access for editing as well as viewing the content, and enable viewing the ensuing discourse around the content using aspects of weblog, wiki, nttp news, or other structurings, according to the content owner and/or viewer's preferences.

Now, i don't see needing to have all features available all together, all the time. However, i do not see any of them as inherently mutually exclusive - in fact, they're often complementary and mutually beneficial. What i want is an easy, unconstricting way to mix and match them when suitable.

I think that packaging many of the behaviors as component-modelish services may be the avenue to realizing this possibility. StructuredText as a mix-in behavior for document rendering is an elementary example. A bit more advanced example: general wiki-style name-link recognition and low-impedence page navigation and creation, and WikiForNow threading/lineage organization could be implemented with a CommonNameSpaces service. These mechanisms, implemented as drop-in catalog indexes and component-model style services, would make these WikiForNow?-ish features available for use with collections of arbitrary content objects, like StructuredText can be available as a mix-in behavior. (See my old OrganizationObjects proposal for more details.)

Connecting this back to ZopeDiscussionModes?, WikiForNow lineage provides a general discussion threading structuring for content collections. Content organized this way need not be presented in a wiki fashion - you could collected it in a weblog arrangement, and also hook it up with an nntp gateway, for interaction as a news collection. It embodies the organizational feature as a reusable service.

When i was working on mailman i saw the maillist archives as an adjunct to the email traffic. I'm more inclined, now, to look at the "archives" as being the content around which discussions are based. Email would be one access mode, nntp news another, the web a third. Services like organization of the content collections (as above), membership for regulating access, and the access modes themselves, would be component-model style services hooked up with the content.

There is an exciting benefit in supplanting the "mailling lists" notion model with a content-centered model. People could "subscribe" to areas (collection lineages) of interest as they notice the development of the areas, and shift their "subscriptions" as their focus on the content shifts. This content-centric model benefits from the greater organizational structurings possible (and common) across the content in a persistent site, as opposed to the more limited flat-namespace grab-bag nature typical of mailling list collections.