[Davical-dev] My thoughts about objects, authentication and other things...

[Matthias Mohr]

Hi everybody,

I've some thoughts about DAViCal development which I want to share with all of 
   you (of course especially with Andrew ;-)

- Regarding the installation guide of DAViCal one requirement is PHP > 5.0
   (BTW, what about libawl? Does it have the same requirement?)
   I think that's fine, that enables proper use of objects, classes and so on
   and should be standard nowadays.
   I assume RSCDS didn't have that requirement and worked in some incarnation
     also in PHP4 environemnts.
   But IMHO it's time to get rid of old habits.
   What I want to say with that?
   To properly define variables and class methods (usage of private, public, 
static, ...),
   to use type hints where appropriate, ...
   Things that are already used as this, but not coded that PHP is able to
     check it.
   What do you think?`
   And how far should it go? (usage of namespaces, replacement of most
     functions without class, ...)

- About the autentication_hook.
   Currently it's just a setting in the configuration where you have
     to include the source (e.g. drivers_ldap.php), set a function
     which'll be called on login.
   Wouldn't it be much better to properly define an interface with some
     needed class methods which then have to be implemented for a new
     authorisatzion method?
   You then could also have a standard implementation from which others
     derive their classes and only implement what's different.

- Global configuration array $c
   Similar thoughts here...
   Why not create "config-objects" for this?
   Maybe with possibility to add own class dependend configuratiion parameters?
   With this you could add specific parameter keys e.g. for the LDAP
     authorisation and get them sent through a check method in the
     corresponding class during intialisation?
     You'll then be able to syntactiacally and logically check the
      configuration parameters...
   Maybe the configuration objects of a certain application part could
      be stored in that part (e.g. as class member)
      and additionally in a global configuration class (e.g. as reference)


What do you think about my thoughts?
Am I thinking in a good direction or is it all to complicate?

Be aware that all of the above is only half-baked and not well elaborated,
just a base for a brainstorming...

kind regards,
Matthias