[dev] Re: Horde 3 docs and framework capabilities

[Eric Rostetter]

Quoting Kevin Myer <kevin_myer at iu13.org>:

> As an example:
> I asked on the main horde list about the resetpassword capability, that
> currently only the customsql driver supports.  I'm looking to add that

Your posting wasn't real clear.  And it was only recent, so not everyone
has had a chance to reply yet.

> for LDAP
> because we have that need here and it looks to be rather trivial to
> implement. So I start looking to find where that functionality exists,
> and its coming out
> of /services/resetpassword.php which uses the Auth classes.  And then I see

Sounds like you pretty much figured it out.

> similar, if not identical functionality coming from the passwd module, which
> appears to be a standalone module under the umbrella of the sork module.  I'd

Passwd is an application to change passwords.  resetpassword is a framework
method of doing the same type of thing.  Passwd existed long before there
was anything in the framework to do it, so it had to do the hard lifting
itself.

Once the framework gets sufficient code to change passwords, the passwd
application will still exist, but it will simply call the framework code to
do the actual work (heavy lifting).

> view resetpassword capability as a special case of password changing in
> general.

Password changing exists at two levels.  One is the low-level actual changing
of a password, which should go in the framework.  The other is the high-level,
user application to change the password.  It exists outside of the framework,
but calls the framework to do the actual work if possible.

So, passwd is the user interface to changing passwords, where as the framework
should (will someday) contain the computer/OS interface of changing passwords.

>  So then I question well, does resetpassword really belong in Auth,
> when password changing in general is in sork (or passwd), and then I ask,

Yes.  The idea is to get the password changing code that interfaces with
the authentication backend into the framework so any application can use
it.

Passwd, as an application, would then use that code.  As could any other
applications which have a need to change the password.

> well
> if password changing is really a basic function of using a web application
> suite, then maybe the functions and classes in the passwd module really
> belong
> in the Auth class,

Yes, or in some similar class.  It would allow for things like changing
the password at first login, reseting expired passwords, etc.  None of
this is handled by the passwd module, which is just a user application
to change passwords on (the users') demand.

> so you'd end up with something like Auth::Passwd::LDAP, or
> Auth::Passwd::Horde, with all the routines being generalized through
> Auth::Passwd and the specifics for each authentication means implemented in
> additional classes.

I can't comment on the specifics of that; I'll leave that to others.
 
> But I have no idea if that fits anywhere into anyone's thinking.  So if

Pretty much in line with convential thinking.  Details may be slightly
off here or there, but you're basically on track.

> I write
> something, where should I write it for?  And how does that fit into the big
> picture of Horde.

If you want to provide a framework functionality, you write it for the
Horde framework.  If you want to write an application, you either provide
the functionality in the application itself (as passwd currently does) or
in the Horde framework and have your application call the framework (as
passwd should, and hopefully will someday).

How it fits in really depends on what your goal is, which I really am not
sure of.  What is your goal exactly?
 
> Its a fabulous framework.  Easy to understand the functions.  Easy to
> integrate
> into a myraid of complex and unique environments.  I just want to make sure
> that I anything I work is developed around the right framework, is done
> in such
> a manner that its useful to others and can be reused by others easily.

Sounds great.  But I think you need to clarify your position.  What is your
goal of your code?  What exactly would your password code do (change password,
handle expiration, interface with the user directly, etc).

> Kevin

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin
 
Why get even? Get odd!