The operations provided here are dealing with the two main data types provided by Hickory, i.e. EventTuple and EventList. Implementation of those routines can be found in HickoryStoreImpl.mesa and HickorySupportImpl.mesa.

Operations that deal with storing and changing event tuples are implemented in HickoryStoreImpl.mesa. The code of those routines is relatively straightforward, so no in depth discussion is provided here. The only thing to worry about is to maintain the cache of entered events correctly. When changing attributes of an event we also must deal with caches of occurrence times in the case of a repeated event.

All the routines dealing with those operations are implemented in HickoryDestroyImpl.mesa. The code should be self documenting. Again the thing to worry about is to maintain cache consistency in the case of a deletion of an event. Forgetting an event does not destroy the tuple, it merely changes the Forgotten attribute of the tuple. As a result, not all queries might retrieve that event. ( see below)

Querying the data base is probably the most tricky thing in Hickory. First, there are a couple of query options provided. Let us explain them briefly:

Further parameters to a query specify the time interval into which events must fall in order to be considered. By providing the key of an EventTuple, it is possible to retrieve the associated tuple.
Note that in thise case the group parameter is ignored. If group is non NIL otherwise, the query ranges over all the events that are contained in the specified group.

The implementation of queries can be found in HickoryQueryImpl.mesa. Again, the code should be self documenting. There is a number of optimizations that are attempted when retrieving events. In particular, when searching for the tuple with a supplied key, we first look into the lookaside cache of entered events. Only if the event is not found there, do we access the data base. Queries are done in two steps when accessing the data base. First all the events with a single occurrence are retrieved. In another query, all the repeated events are retrieved and if the ExpandRepetition bit in options is set, all occurrences of that event falling in the given time inteval are generated. The rationale behind doing two queries to the database, was the belief that the list of repeated events would be much shorter than the one of single events. Hence, we don't have to traverse a long list of events in order to find repeated events, expand those and then reorder the entire list. Rather we deal with a larger set of short lists, which is more suitable to most of the algorithms which are O(n) in the length of the lists we are dealing with.

All the operations relevant to groups are implemented by HickoryGroupImpl.mesa. Events can be grouped together by using routines exported by either Hickory.mesa or HickoryGroup.mesa. A group in this context is a set of events. This means that an event can be member of several groups at once. Removing it from one group, does not automatically remove it from another group.

The association between an event and the groups it belongs to is registered in a particular relation. In this relation there is an index on the events, thus making retrieval of the groups of a particular event relatively efficient.

HickoryGroupImpl maintains a cache of all groups that are declared within Hickory. This makes the ListGroup[] operations particularly fast, but as inconvenience we have to maintain cache consistency correctly.

There are certainly other possibilities of providing grouping semantics on events within the Cypress interface. I have used a simple and straightforward approach, which had the big advantage to be operative in a relatively short time! I felt that using the subdomain facilities was rather akward and might indeed not have provided the same semantics.

With each event one can associate any number of properties. Properties are characterized by their name and their value. The value implicitly declares the type of the property. Currently values can only be REF INT, REF BOOLEAN, REF Rope.ROPE or REF BasicTime.GMT. This is a limitation of Cypress. Once the type of a property is declared, all furhter values of the named property must be of the correct type, otherwise an error is raised.

Properties are implemented as relations between events, property descriptors and the value. A property descriptor describes a property by associating a key with a property name. As a result of this schema, there is one relation per data type, since Cypress does not really allow for storing entities of any domain type.

The reason to implement properties through a set of relations rather than using the property operations of Cyprress, was the fact that Cypress does not allow to store attributes of domain AttributeDomain. Despite what the documentation claims. One could have gotten around that by redeclaring a property with version = OldOnly upon a query. But this seems to be as akward as the way it is done now. As far as efficiency is concerned, it is hard to make a statement. Having an index on the events stored in a property relation, is certainly helpful in retrieving a property of a given event.

Hickory serving as shared data base to several clients ( currently Calendar and Remember) it is mandatory that clients can be informed when the data base is modified. The HickoryNotifyImpl.mesa monitor provides the needed primitives. Note that this monitor is having a separate monitor lock and does not use the lock provided by HickoryStorage.protData. A client can register a procedure of type Hickory.NotifyProc. Whenever a write change to Hickory occurs, HickoryNotifyImpl forks off a process for each registered notification procedure. The parameters of the notification always include the reason of the notification. If the change is specific to one event, the key of this event is also passed to the client. Occasionally, further information is passed through the data parameter.

There are a couple of things of importance in this context. First, Hickory must guarantee that clients are notified when changes occur. This implies the right calls being made to HickoryNotify from within Hickory. Second, the client must deal with a notification in an appropriate way. This means to analyze the reason argument and then take the appoprite actions. As a further caveat, the client must be able to handle notifications that occur asynchronously. This probably means that the Hickory data being cached within the client must be protected through a monitor!?

The implementation of Hickory includes some additional modules. Let's enumerate them and briefly describe what they do.

One of the more original aspecs of Hickory is the possibilty of dealing with repeated events. Quite obviously those kind of events occur quite frequently in every days life, thus giving an incentive to deal with such things. We shall now describe to some larger extent how Hickory deals with such repeated events.

An event is marked as being a repetitive event through the RepeatType, RepeateTime and RepeatUntil attributes of a tuple. The first of those attributes indicates the kind of repetition. Except the Complicated type, they are obvious. When the repetition type of an event is complicated, RepeatTime is used to specify the repetition interval. RepeatTime must be Rope.ROPE that Tempus.Parse can understand. For instance, "60 minutes" or "2 hours" are legal values. RepeatUntil gives the time when the repeated event happens for a last time. As start time, we use the EventTime attribute. For each repeated event, we only store the tuple representing the very first occurrence and the repetition descriptor.

When we discover a repeated event ( RepeatType # None) we then must query the repetition descriptor in order to compute occurrences of the repeated event in the given time interval. Computing repeated occurrences of the event is straightforward in principle, but computationally expensive. In fact, we compute Ti+1 = Ti + Dt. One problem is obviously the non linearity of the gregorian calendar system. A month can have 28, 29, 30 or 31 days, so how many seconds do separate an event that happens every 2 months? The same is true for other repetition intervals. Hickory uses Tempus.Adjust to deal with that particularity.

Another aspect to the problem is to find out the events happening in the interval [ t1, t2], knowing that the first occurrence was at t0 and also knowing Dt. The straightforward approach is to start generating time points ti until t1 <= ti <= t2. This approach is computationally expensive. In order to attempt reducing the costs, Hickory provides a cache of time points on which a repeated event has happened. When attempting to compute an occurrence of a repeated event, we first look into the cache if there is some time ts, s.t. ts <= t1. Doing this reduces the length of the generated sequence of time points. Only if no suitable time can be found in the cache, do we have to start generating the sequence from the first occurrence of an event.

The caches used in that scheme are implemented in HickoryCacheImpl.mesa. Two constants are of relevance: the cache size and the cost factor. The latter decides how often we insert newly generated time pointes into the cache. A cache itself is an increasingly sorted array of time points, bound to a particular repeated event. Once the cache is full, elements are deleted more or less randomly upon insertion of a newly computed time. Having to maintain the order of the cache makes insertion of newly computed time points relatively expensive. Given the rather large cache size and the assumption that time intervals of successive queries are not spread out too far apart on the time axis, the overall efficiency should be satisfactory.

Caches of time points are periodically saved onto stable storage. The aim again is to keep track of time as it goes by. Query intervals are indeed assumed to be progressing on the time axis. In other terms, if Query1 specifies a time interval [ t1, t2], we think it is very likely that a subsequent query, Query2 uses a time interval [ t3, t4], s.t. t3 > t1.

A further point of interest when dealing with repeated events is the LastOccurred attribute with a repetition descriptor tuple. As real time goes by, we keep this attribute up to date; i.e. for a daily event we generate the occurrence of it on every day, although we might not necessarily do a query on that day. If however we then make a query for today, we know the occurrence of the event of yesterday and can rapidly generate the occurrence time, without having to use the very first occurrence ever. Again, this is a heuristic approach and might only be of limited usefulness.

One of the rather nast aspects of transactions, are aborts. How does Hickory deal with that?

For one, all client calls to Hickory are implemented as one single transaction. The very first thing we do, is to make certain that everything looks ok. This means a transaction must be open. Once this condition is met, we proceed with the transaction proper. At the end of it we mark the transaction through the appropriate call to Cypress.

In case of an abort, we handle the raised exception as follows. The transaction is closed and we reinitialize the data base scheme. Then a new transaction is opened and we reexecute the entire transaction. When opening a new transaction after an abort, we wait until no other transaction is open on the data base segment. This is aimed to reduce further conflicts. When restarting transactions, we only try once. A repeated failure will generate an error, not caught by Hickory.

Currently transactions are started over until they finally succeed. This might not be a totally good idea, since could bring us into a kind of infinit loop..... Currently however the implementation seems to be sufficiently stable for moderate, careful use.