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.

Reply via email to