call me crazy, but putting that in libapreq2 seems like it would:
bloat the code with unnecessary api functions (as not everyone would
use it - i only use session stuff on 1 of 4 projects that are running
under libapreq)
create new avenues for bugs
add new functions/logic for the developers to maintain, making
releases further apart
your idea sounds like a perfect plan for a seperate, yet libapreq2
dependent authentication library - which would not only nullify any
negative impact it could have on libapreq, but offer customization and
be really badass
On Sep 22, 2005, at 9:57 AM, Eli Marmor wrote:
Sorry for being not enough clear: I didn't speak about HTTP
authentication, and even not about a library doing the authentication
for you. All I spoke was about some convenient routines that may save
80% of the work for people who implement cookies-based or session-based
authentication.