Remember, account activation is optional, so this would only solve
half the problem (the whole problem for Hub, since it uses account
activation). We could have separate logic for the non-account-
activation scenario, but that seems overly complicated
4. Use the preferences system to implement this feature.
We built out a system for storing arbitrary key-value pairs on the
server side to implement preferences, couldn't we use this instead
of a cookie to implement option 2?
Shoot, this actually might not work, since we need to authenticate to
store preferences. Hmph. I'll keep thinking on this today, but I
guess this means we need more discussion on this thread.
The one downside is an extra server call, but we could have the
code only check for a pending subscription the first time a user
logs in. We already do this to add a default calendar to a user's
account, so that would probably be a reasonable location for this
logic. This would mean the Web UI performs a check for pending
subscriptions any time the user has no calendars, but I think
that's a pretty minimal cost.
Thoughts?
I believe we had a discussion on the list to see if it was
necessary to keep the out of the box 'Chandler Hub' calendar. I
think for now, I don't see much harm to keep a blank calendar for
the CC users. When we introduce remove, perhaps they would be
able to remove it from their list?
Any thoughts on this proposal?
-Priscilla
I think it's a good idea anyway to give CC users their own empty
calendar in the Web UI. It's a way of encouraging them to try it
out themselves.
+1, especially since there is currently no mechanism for adding
calendars.
-Travis
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
