[MKDoc-dev] Proposed event/calendar functionality

[Bruno Postle]

On Wed 13-Oct-2004 at 13:22 -0400, Sam Tregar wrote:

> I think I understand what you mean by an Event, but what do you
> mean by a Place?

This would allow a document to have geographical coordinates.

> Or is this future work that doesn't require consideration
> now?

I mentioned it as a complementary related concept, it isn't
something we are going to build any-time soon unless someone can
think of a really good reason.

> Does a calendar component already exist or what that be part of
> this development too?

A complex tabular calendar could be implemented as a plugin - Much
like the existing Finder, but it isn't necessary at this stage.  

What does need to be implemented is a listing of 'upcoming events'
component, this would be similar-to or an extension-to the existing
headlines component.

> Does the editor have to manually add each instance of a repeating
> range?  For example, an event might occur every other Wednesday
> from 4pm to 5pm.

I think so, otherwise we are going to end-up implementing the entire
iCAL specification and the user interface is going to be beyond
anything we can expect a normal user to cope with.

> Will the data be replicated, i.e. stored in both the Body and in
> the Component_TimeRange table for searching?  Or will the data be
> stored in the Component_TimeRange and merely referenced from Body?

Good question, you are touching on the central design issue of
MKDoc.  We have a system where the 'content' of each document (a
list of components) is stored in a single place as an XML blob.
This has advantages and disadvantages: it's extendable and easy to
access, but hard to search directly.

But events have to be easily searchable, we can do this in two ways:

1. Store the data in the XML blob and cache the relevant bits of
   information in an index for later searching - This is how the
   existing search engine works.

2. Put the information in it's own normalised table and just put a
   placeholder in the document itself.

(1) is very much in the spirit of the existing MKDoc, (2) would be
taking it in a direction that might ultimately result in all
'components' being stored independently of the document itself.

It was part of the original plan years ago to migrate to such a
system, but this existing system works very well - Why break it?

> Can you elaborate on why Document_ID is missing and why this is
> important?

It's missing because it was just pasted from the initial unfinished
implementation.  When I looked at it, there was clearly no way that
an item could be easily related to it's 'parent' document.

It isn't clear if this unfinished implementation was intended to be
(1) or (2), it looks like neither and the original author isn't
available to ask.

-- 
Bruno