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

[Andrew McMillan]

On Thu, 2009-10-29 at 14:36 +0100, Matthias Mohr wrote:
> 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?)
Yes it does.

>    I think that's fine, that enables proper use of objects, classes and so on
>    and should be standard nowadays.

It has only been a recent change to DAViCal, so the effects are only now
becoming apparent.  For example it is only in 0.9.8 that I have started
to change class definitions to use public/private/protected rather than
'var' in the object definitions.


>    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?`

I agree.

>    And how far should it go? (usage of namespaces, replacement of most
>      functions without class, ...)

I don't see that putting all functions into classes is necessarily a
good thing.


> - About the authentication_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
>      authorisation method?
>    You then could also have a standard implementation from which others
>      derive their classes and only implement what's different.

It is already an interface, though not one which is defined through an
object. It is defined as a function, accepting two parameters (username,
password) and returning an anonymous object (the user record).

This was *intended* to be as simple as possible, and to work with PHP4,
so it's possible that an object interface might be able to make it more
accessible by including the three utility functions that from
auth-functions.php.


> - Global configuration array $c

It isn't an array: it is an anonymous object.  Over time I think it may
well become a real object.

>    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)

I would certainly like to get rid of the configuration-parsed-by-PHP
problem and have something which reads a plain text file.  It's tempting
to use YAML for this through php5-syck but it introduces another
dependency, and one that I have seen being hard to find in some
circumstances, so I'm not sure.

On the other hand, whatever configuration interface we can come up with
should still allow nested structures.  Perhaps it should also (in due
course) allow for the configuration to be loaded/fetched from memcached.


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

It's fine.  I think in the first instance that looking at wrapping the
auth stuff is the simplest entry, and least likely to run into problems
with my current work.

Changing the configuration stuff will be quite tricky and won't happen
quickly, as we need to give the users backward compatibility for a few
versions, along with some automatic (or near automatic) upgrade ability.

Cheers,
					Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
     Building more free and open source software for New Zealanders
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20091030/a5faa44f/attachment-0001.pgp>