Re: PIM status

From: Erik Bågfors <erik_at_bagfors.nu>
Date: 13 May 2002 11:34:11 +0200

On Sun, 2002-05-12 at 19:09, Philip Blundell wrote:
> 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
> )

I would add "summary text" here as well. That's how the palm,
evolution, VCAL (haven't looked at Icalendar) works. Summary is what
you normally see in the calendar-view and if you open the event you'll
see both.

> 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;

I'd change RECUR_MONTHLY to RECUR_MONTHLY_BY_DATE and
RECUR_MONTHLY_BY_DAY. Again, I _think_ this is how the palm, evolution
and VCAL does.
 
> 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.
>

I kinda like unix time but the downside is that some people likes to put
birthdates on the date a person was born and then do RECUR_YEARLY on
them. That will not work if you use unix time since lot's of people were
born before that. Also, should we care about timezoones?

> 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
> )

Add summary text here also.

/Erik

-- 
Erik Bågfors               | erik_at_bagfors.nu
Supporter of free software | GSM +46 733 279 273
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Received on Mon May 13 2002 - 09:34:20 EDT

This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:18:59 EDT