In the previous discussions about how to do this, there were a
three possible approaches we discussed:
1. Adding the subscription on the server-side after the account is
created, but before it's activated.
The benefits of this approach are obvious -- the subscription is
added to the account right away, and nothing can happen in between
creating the account, getting the e-mail, and verifying/activating
the account that would cause the subscription to be lost.
IIRC, the major downside of this approach is that it was deemed to
be difficult to implement because of the inflexibility of our
security model. (I believe there were also concerns that allowing
subscriptions to be added to a not-yet-activated account could be a
security risk, which seemed a little dubious to me.)
There are actually a couple different ways we could implement this one:
a) Add subscription information to the CMP data model, so that we
could create users with subscriptions in one step.
I don't like this, and I know Brian didn't like it when I proposed
it, as it mixes up our data models. Information about content is not
currently part of CMP, and it would be a pretty big departure from
the protocol to do this. That said, I'm open to discussing it.
b) Punch a hole in our security to allow subscriptions to be added to
unactivated accounts. This could be done by:
i) Building a special exception for certain operations into the
method that decides whether or not a user is activated (and thus
whether or not a client can authenticate as the given user). This
seems really crufty and ugly, building information about our
protocols into our auth code.
ii) Allow anonymous clients to add a subscription to a user. This is
definitely a security hole. Spammer add bogus advertising
subscriptions to arbitrary calendars, Cosmo becomes object of
ridicule. Out of the question in my mind.
Any other ideas?
2. Storing the information about a 'subscription to be added' in a
browser cookie, and adding the subscription after the user actually
logs on to the new account.
The benefit of this approach is that it doesn't require any server-
side work.
The downside is the inherent unreliability of cookies. For example,
if the users completes the account-activation process from a
different browser (e.g., goes home from work and checks e-mail
there), the subscription will not get added to their account.
The bottom line would be that we can't assume the process would
always work, and end-users in those cases would be left wondering
why it didn't "add this
subscription" like it said it would.
Agreed, I don't like this either.
3. Change the activation e-mail to include information about the
desired subscription, and put it into the URL for the confirmation
page.
The benefit is that approach is that the info for the subscription
is in the actual e-mail, so it comes along with the users to the
activation and login pages -- no matter where they log in to the
app from.
The only drawback I can think of is that it would require some
amount of server-side work. There may be others. I would appreciate
feedback from Travis on this.
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?
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
