[dev] Re: Horde 3 docs and framework capabilities

[Kevin Myer]

Ok, I'll start over, because I'm trying to get a grasp on conceptual issues
first, before implementing specifics and probably didn't spell that out first,
before stumbling on to something else.  Eric's clarifications help me 
focus and
maybe rephrase what I'm trying to say (hopefully :)

I'm looking at this from two angles:  1) maintaining a working production
FRAMEWORK_3 installation, and 2) filling in the gaps for our 
environment, where
the framework exists for something but has not yet specifically been
implemented (like password resets for LDAP authentication backends), and
wanting to make sure that any work that we'd do for our organization 
(either by
myself writing it, someone else writing it, or however it would get 
done) would
be done in such a way that it fits and could be reused by others.

First is there a current ROADMAP type document I can read, so that I can
understand where Horde 3.1.X might be headed, or Horde 4.X might be headed, or
the specific modules might be headed?  Or is that simply a 
concatenation of all
the docs/TODO files and the items they list?  There are links for API
documentation to see what exists now, class and function-wise but what 
does the
future hold for that and for features in modules (i.e. resource scheduling in
Kronolith)?

Second, when do point releases drop?  For example, Turba 2.0.1 had 
several fixes
in it.  Turba 2.0.2 dropped a day later with one fix for browse mode (maybe a
showstopper bug, but I don't use the browse mode often so I wouldn't have
noticed it if I went from 2.0.1 to 2.0.2).  I think I've got a handle on API
changes from the Horde3 Development note in the wiki.  But what about things
like database schema changes?  In maintaining a production environment, am I
going to have to worry about potential schema changes, data conversion, 
etc. in
Turba 2.0.X, or will I be able to focus internal testing on reviewing code
changes in the application only?  If I'm tracking the FRAMEWORK_3 
branch, would
it be better to forget about point releases and just watch CVS commits to that
branch as they come along?  Knowing that will help me understand what kind of
change management process I need to have in place - whether waiting for point
releases will suffice or if I've got to track incremental changes closely.

Third, are there useability guidelines, to help promote a "Horde" look 
and feel
and way of doing things?  Examples:  use of "My [Calendars,Tasks,Notes]"
provides a consistent way of accessing your things in each module.  I 
suggested
My Folders in IMP to keep with this theme, as well as overlaying the Horde
Permissions (as best as they can fit) over IMAP acl, because if you 
know how to
assign permissions for a calendar, you know how to do it for a notepad, and a
tasklist, and potentially mail as well.  Another example - consistent address
expansion across applications - in IMP, you've got Tab autoexpand, Expand
Names, and an Address Book link.  In Kronolith, on New Event, you've got an
Edit Attendees link, which has a button to bring up the Address Book.  What
about adding Tab autoexpansion, and an Expand Names icon, and an Address Book
icon there, all with the idea that if you're in a Horde application, and you
are dealing with addresses or names, you can get at the addresses and names in
the same way, because its consistent.  Working with a beta group, we're 
finding
a few tweaks here and there that would definitely enhance useability, with the
main common theme being a consistent way of doing things.

So those are the general concepts I'm trying to get a handle on.

Now for a specific example, the resetpassword function and the passwd 
module. resetPassword is currently implemented in the Auth class.  So 
for a very
specific case (user can supply secret_answer to secret_question && Auth
backened supports changes), it can be reset directly from within the Horde
Framework.  If you're an administrator, you can go into Administration and
Users and setup new users and set and change passwords as well (or at 
least the
framework is there to do it, I think in updateUser - I just threw up 
exceptions
and ldap errors when I tried it on a demo account - ah, I see that's because
Auth->updateUser always returns unsupported :).

But, currently, to provide users the ability to change their own 
passwords, you
have to install the passwd module, which implements the Passwd class.  So lets
say I need to implement some zany new idea I have that relates to passwords
(purely as an example).  Do I implement it in the Auth class, which contains
the resetPassword functionality?  Or do I implement it in the passwd module
Passwd class?  Or, would it be a good idea to move the passwd module Passwd
class into either the Auth class in the Horde framework or make it be a
standalone Passwd class, outside of Auth, but in the Horde Framework?  
Or would
it be a good idea to have Auth->updateUser rely on having the passwd module
installed and return unsupported if its not, and implement the Passwd routines
from there if it is?  Ultimately, thats immaterial to how I'd implement LDAP
resetPassword capabilities, because thats already confirmed to be done through
the Auth class.

But after studying things related to passwords, in anticipation of making the
LDAP enhancement, I'm just confused about why you do resetPassword one place
and general password changes elsewhere and what the future plan might be for
gluing all that together..  Should the Passwd class be pulled into the Horde
Framework?  Or would you extend the Auth class with a Passwd class, which
itself is extended by all the supported backends.. (which would make, as a
requirement for password changing, that you have the passwd module installed).

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org
(717) 560-6140