On Sun, 2002-05-12 at 17:08, Owen Cliffe wrote:
> Now that there is code for PIM does anybody have any improvement ideas
> for the the PIM schema.
One important improvement would be to add support for storing events.
:-)
The table that gpe-calendar uses currently looks a bit like this:
create table events (
uid integer NOT NULL, -- unique ID
start integer NOT NULL, -- Unix time
duration integer, -- in seconds, zero for alarm-only events
alarm integer, -- in seconds, time before "start" to
-- sound alarm. NULL if alarm not required.
description text -- just what it says
)
This still lacks support for recurring events. Internally, gpe-calendar
represents those as:
typedef enum
{
RECUR_NONE,
RECUR_DAILY,
RECUR_WEEKLY,
RECUR_MONTHLY,
RECUR_YEARLY
} recur_t;
struct
{
recur_t type;
unsigned int count; /* number of days, weeks or whatever */
unsigned int daymask; /* bit 0 = Mon, bit 1 = Tue, etc */
time_t end; /* no recurrence after this time;
0 = forever */
} recur;
and it might be reasonable just to translate that directly into SQL.
It's not completely clear to me what the best way to represent calendar
time is. Unix time is unambiguous and (usually) easy to manipulate, but
doesn't necessarily do what you want when different timezones and/or
daylight savings are involved. I haven't done any investigation of how
other PIM apps handle this.
There probably also wants to be some way to specify what sound to play
when the alarm goes off.
As for to-do stuff, gpe-todo uses a two-table scheme:
create table gpe_todo_lists (
id integer NOT NULL, -- unique ID
description text -- title of this list
)
create table gpe_todo_items (
id integer NOT NULL, -- good ol' unique ID
list integer NOT NULL, -- list of which this is a part
state integer NOT NULL, -- completion status
description text, -- pretty self-explanatory
due_by text, -- date, time in ISO format,
completed_at text -- ditto
)
p.
Received on Sun May 12 2002 - 17:09:46 EDT
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:18:59 EDT