History for KenManheimer

??changed:
-
KenManheimer's ZopeDiscussionModes Mission Page

  mailto:[email protected]

  I'm a developer with "Zope Corporation":http://www.zope.com, and
  have had a hand in a number of discussion-oriented collaboration
  tools while here, and before: an "issue tracker",
  http://www.zope.org/Members/klm/TrackerWiki , "wiki enhancments",
  http://dev.zope.org/Wikis/DevSite/Projects/WikiForNow , and work on
  the "Mailman maillist manager":http://list.org.  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",
  http://dev.zope.org/Wikis/DevSite/Projects/WikiForNow
  threading/lineage organization could be implemented with a
  "!CommonNameSpaces", http://cmf.zope.org/Members/klm/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",
  http://cmf.zope.org/rqmts/proposals/OrganizationObjects 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.