I'm ready for the mechanism to get added to the code now. Here's what
I want.

1. Let's not create a separate Cabal package, after all. Based on the
success (so far) of AuthSite.hs, I think it's enough abstraction to
have distinct tests and a good module interface.

2. All actions should be recorded with timestamps into an Event table.

3. The API for the module should be event-based. The conceptual model
is "reactive", meaning that the outputs are a time-dependent value of
the inputs.

Inputs:
    1. Patron joins the crowd at time t
    2. Patron leaves the crowd at time t
    3. Patron makes a donation at time t

Outputs:
    1. Number of patrons in the crowd at time t
    2. Current pledge value at time t
    3. Patron X's crowd membership at time t
    4. List of Events that occurred before time t

Behind the scenes we'll just bash it into place by separately
inserting a row in the Event table for each modification made to other
data. Eventually it would be Rad to actually build something reactive
in the database layer, but that's not on the critical path.

Separately from the mechanism, we need to interface with
$PAYMENT_PROVIDER. Internally, we've sort of been talking as if that's
Stripe. I think we should just make that official and start reading
their API and figuring out what the UX is and what the business rules
are.

I'll be (out of the country)^2 for the next week so I won't be working
on this personally just yet. :)

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Reply via email to