TJNII
commented
10 years ago Adrian's thoughts from #2
Mobile blood banks and mobile food drives are other components but that is covered by address and allowing a broadcast to expire...
There you go! Allow a trigger for expiration date, what you think? Broadcast for need and Broadcast to give, both have a selection of a expiration date.
So I'm thinking time requirements should be set for the passive mode we discussed for both donors and recipients. As this will be DB backed a proper search query will be able to address the time restrictions.
As for the active search, I don't think expiration is relevant. I envision the active search to be "show me everyone who is in the DB right now" with the intention of having the searcher take action. As the active search doesn't (necessarily) store DB data we can't broadcast off it.
For the broadcasts I envision donors/recipients needing to save data (passive flow). Off that we can then trigger off the database update to run a backend job to get the broadcast behavior we want.
I think if we add expirations the way I'm thinking we can get the broadcasts as you're thinking without too much trouble. I think the plan is sufficient to get us to the next hackathon, I'm going to stay on plan with the API for now. (We stopped before defining the save to the backend API query, after all. :P )
In the current plan timeouts and waiting periods were only defined for donors, as a donor may only be able to donate something on a timetable and frequent notifications would just be noise. However, the ability to specify expirations and timeouts for recipients may also be valuable for cases like: