🚀 go-pugleaf

Actually, the question I asked in the summary of how my calendar
program works was intended more along the lines of "does anyone have
any major problems with this model," supposing that it actually does
do most of the things you would want reasonably. I left out a lot of
details about the system in order to just present the model, but here
are some more details of it in answers to Alan Wexelblat's comments.

> First off, there are the standard problems with using email for
> notifications in that (1) you can't tell when/if a message is delivered; (2)
> you can't tell when/if someone's read the message you're interested in.

(1) The server I have written does in fact remember whether or not a
user has seen a given message, and currently passes this information
to the application should it ask. I'm not exactly sure whether I
should have the application give this information out, because it may
conflict with some users' feelings about privacy.
(2) You can never tell if the user has read something in an automated
system unless they tell you in some way. You could tell whether or not
it had been shown to the user, but I have no plans for this.

> What will happen when two people have "incorporated" the meeting into
> their calendars, but then the organizer decides to change it as a
> result of one person's objection?  Can the other calendars be reliably
> "rolled back" to the state they were in before incorporation?

Yes. Each transaction through the server has a unique number, and all
related transactions subsequent to it (be they changes or responses)
refer to it as a base.

> Third, if someone wants to counter-propose, how will they know a good time
> to suggest?  Will they have access to the same set(s) of calendars that the
> meeting originator did?

Good question. Accessibility of a calendar is strictly up to the owner
of that calendar (according to the file protections they have set on
the file or directory). The concept of counter-proposals, except for
meetings of only two or three people, may not be practical; the best
thing is probably just to say "no," and list a set of good times, or
say why this particular time was bad (if it was in fact unscheduled).

(me:)
>    In addition to this, the recipient chooses whether to
>    add this appointment to the calendar or not, and whether or not it
>    should show up as time that s/he is "busy."

(Alan:)
> The concept of adding an appointment but not having the time show up as busy
> strikes me as kind of odd and likely to increase your rate of collisions.

Um... This feature is intended to make it a choice of the user. They
may want it to show up on their calendar, but not actually plan to
attend, and so don't want it to show as busy. I wasn't too explicit. :-)

> Fifth, if I have made a response/counter-proposal to a meeting, how long
> must I wait to know if that time is committed or if my suggestion will be
> adopted?

Say the meeting is created tentative, and you counter-propose. This
will go back to the initiator, who after getting a sufficient number
of replies, will decide what to do, be it try a reschedule or finalize
that time. They will at that point send out a reschedule or finalize
message. Reschedule/finalize/cancel will be handled decently by the
application due to the aforementioned transaction number. So it's up to
the initiator how long it takes.

> Do I see other people's counter-proposals?

This is not planned, but simple to add. You will just see the updates
from the initiator.

> None of these are total show-stoppers, but you *did* ask...

Yup! Thanks.

Unless people are generally interested in all this, any further
questions about details may want to go straight to me.

Craig Fields       cfields@athena.mit.edu
MIT-Project Athena