[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Recurrence Rules -- are they needed?



Looking at the grammar again, I really wonder if the Recurrence rules
as defined in 2.2.22 are needed.

It seems to me that they are overly complex, and could lead to bad
implementations which would cause errors.  

I was wondering why not just use an enumeration of the events.

For example:

Instead of  RRULE:YD2  1 2 3 #5 which is supposed to mean every
other
year on Jan, Feb, March why not just have RDATE:19960101;
19960201; 19960301; 19980101; 19980201

It is cleaner, and less complex to understand at the expense of a little
bit more bandwidth.  I don't see the need for RRULE at all.

As an aside, I recently heard that U.S. elections are on the first
Thursday following the first Monday in November, every four years.  I
could not see how to code that using RRULE, can it be done?


On a different topic, does anybody think it would be useful to have a
history property to help reconcile modifications between different
servers.  I was thinking something a little more robust then current
sequence number.

For example everybody (Ann, Bobby, and Charley) are on a different
server.

Time 1:
Ann sends message to Bobby and Charley about meeting (sequence:
1; history: ann-1

Time 2:
Bobby receives message, accepts and sends it to others
(sequence:2; history: ann-1, bobbi2)

Time 3: Charley recieves message (from time 1), declines and sends
it to others (sequence:2, history: ann-1, Charley-2)

Time 4: Ann receives message from Time 3, that has Bobby as being
tentative and Charley as declining.  Since sequence is 2, and last
seen version had sequence 1, the current message replaces the old
message.

Time 5: Ann receives message from Time 2.  Sequence number is 2
which is the same as the last seen event (what should be done).  With
history comparisons it is possible to see what was modified, and
realize that Charley is declining.

The problem gets realy nasty when in 
Time 6:  Charley changes his mind and is not sure if he will attend, and
changes his status to Tentative.

The problem stems that there is no clear protocol on the order of 
transmitting messages for modifications to a meeting.  Something like
saying that a server modifying a message must notify only the
originator who is responsible for notifying all other servers could solve
the problem.