KendraBase - Moving To 0.1

We currently have a demo that is somewhat schematic. This needs bug-fixing and additional features before we can show it even to a small group.

These are:

• "document" abstraction
• user logins
• dictionaries
• making the class / instance stuff bulletproof
• adding custom forms

All of this then produces a very simple concept model application which can be offered up for criticism.

Having gathered feedback, we can then start work on producing a proper application. This will involve rewriting from scratch, but with a design based on insights from the original prototype and feedback / criticism from the Kendra community.

Features that are anticipated to be added in the new application:

• access control lists for objects (or are capabilities the way to go?)
• "fixed" classes objects

The aim is to produce a version 0.1 release.

This is intended to be:

• a public source code release
• copyrighted by the Kendra Foundation
• with complete copyright and licence code headers attached
• with properly commented / internally documented code
• with (provisionally) stable internal and external APIs
• released into a source code repository (arch? CVS?)
• with a unit test suite

We should have a set of intermediate milestones, provisionally:

• 0.0.1
• 0.0.2
• 0.0.3

...

• 0.1

Some simple low-level software design principles

• Software contracts for procedures
• Command / status separation

Things to abstract out

• the click - perform action - generate output page loop (model / view / controller)
• different M/V/C modules should be "hooked" into the main body of the code
• persistent session model, and integration of forms, GET parameters and cookies
• use our own abstractions internally as soon as possible

Reminder

• The aim is not to write Zope or PostNuke?!
• We should aim tightly at our core goals
  • data indexing
  • data querying (note: only within the KendraBase cloud: not a general-purpose tool! (yet?))
  • annotation
  • free-form object description

and

• not at content management
• not at efficiency
• not at being all-encompassing in terms of being a Web platform
• we are only a data platform, with a stripped-down user interface

but

• we aim to provide hooks for the major platforms

See KendraBaseProgress for more.

See KendraBaseFutures? for some speculation on what might follow when we get this far.