On 04 September 2002, Andrew Kuchling said:
> Stray thought: Greg, would the user classes need to be distributed
> with Quixote at all?  Could they be an entirely independent package?
> Maybe it's best to keep Quixote focused on one specific task, mapping
> URLs to function calls.

I disagree; Quixote is a web application framework, not just a toy for
mapping URLs to function calls.  We already include significant code for
generating HTML forms and handling web session management, and
not-entirely-trivial code for sending email.  These are all common web
development tasks that have little or nothing to do with mapping URLs
onto function calls.  Ditto access control.

I think the line we want to avoid crossing is the mechanism/policy
boundary: ie. as soon as someone proposes adding functionality that
would constrain Quixote apps to one particular way of doing things, we
must say "No".  The most immediate example that springs to mind is in
access control: do you store cleartext passwords or password hashes?
That's a question of policy that must be decided by the application
developer, so Quixote must either avoid the issue entirely, or provide
both approaches.

(My current thinking is to provide an abstract User class [it would be
interface if this were Java] along with two implementations: one which
stores cleartext passwords, so the app can email users their forgotten
passwords, and the other which stores only hashed passwords for
security.  Then application developers will just have to pick which User
class is appropriate for them.)

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org