Thanks both, I will probably go with the no-continuations solution, since I am virtually certain that I will change the code while it is running - it runs over several weeks, and I sure to muck up both on survey and program design.
Cheers, great feedback, Marc On Mon, Jan 4, 2016 at 2:15 PM, Jay McCarthy <jay.mccar...@gmail.com> wrote: > On Mon, Jan 4, 2016 at 2:11 PM, Neil Van Dyke <n...@neilvandyke.org> > wrote: > > Jay's example is a clever use of `web-server` continuations. If I > > understand this example correctly, some comments... Note that this > approach > > requires that the continuation for a survey participant still be > available > > when the participant clicks the link in their email. If you use this > > approach for a survey for which people have hours or days to respond, > you'll > > probably want to persist the continuations in a database or file store of > > some kind (that's longer-lived than the Racket process, though I don't > > recall the options `web-server` has for this). And also not let the > > framework expire the continuation for a participant while you're still > > entertaining the possibility of their participation. Also, you might > not be > > able to update your server software once the survey is started, due to > the > > continuations hanging out there. > > If you use "#lang web-server", all these issues are resolved, except > updating the software. > > > An alternative is to forget about continuations hanging around, and keep > the > > random key in database table (such as in PostgreSQL) of the participants > in > > a survey. You probably are storing some information about participants > and > > survey responses, anyway, and the key for a survey is just another > attribute > > in the conceptual data model (e.g., an attribute of the Participation > > association/relationship between Person and Survey, if that's how you > model > > it). You can generate a random key string for the URL with the `random` > > procedure and string operations (or read from a source like > "/dev/random" or > > "/dev/urandom" if higher security). If users might have to type the key > > manually, you could make it all-lowercase ASCII letters (base 26), > separated > > by minus characters into groups of 3-4 letters, and not too long overall. > > > > Also, you might have to detect and/or thwart attempts to brute-force the > > keys, or to at least at some point check the logs for signs of > > brute-forcing. Some online surveys tend to get gamed, for > > ideological/political/business/amusement reasons; I don't know whether > > that's an issue for your particular survey. > > All good advice. > > Jay > > -- > Jay McCarthy > Associate Professor > PLT @ CS @ UMass Lowell > http://jeapostrophe.github.io > > "Wherefore, be not weary in well-doing, > for ye are laying the foundation of a great work. > And out of small things proceedeth that which is great." > - D&C 64:33 > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
