[dev] Re: Horde 3 docs and framework capabilities

[Chuck Hagenbuch]

Quoting Kevin Myer <kevin_myer at iu13.org>:

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

Right now bugs.horde.org and the TODO files are the best we have. There 
was a pretty solid roadmap in the Wiki for the Horde 3.0 release 
process - 
http://wiki.horde.org/display.php?referrer=ReleaseManagement&page=RoadMap. And 
there were roadmaps on the web site for a time, but they were getting 
stale so they're down for now.

> Second, when do point releases drop?

When they're ready, and when it feels like time, and sometimes sooner, 
if it's a showstopper or security issue, or if someone is bored (or 
perhaps feeling stupid for having let a bug slide into something that 
was just released). Sometimes when people poke us that there are fixes 
sitting in a branch and we should roll a release.

> 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

No. Point releases are for bugfixes and *minor*, backwards-compatible 
changes only. Minor exceptions like fixing $conf['session']['timeout'] 
sometimes happen for important bugfixes, but that's very rare and we 
try not to do it - for that one, there was no way to properly fix the 
problem without breaking *something*. Anything requiring a conversion 
script will be a minor release, at least (Turba 2.1, etc).

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

Sorry, not sure better than what? The changelogs are pretty thorough 
for the point releases and are included in the release announcements...

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

Kind of depends if there's a bug you urgently need fixed, I guess?

> Third, are there useability guidelines, to help promote a "Horde" look
> and feel and way of doing things?

Nothing written up. There's certainly an unwritten sense of it, though 
- formalzing it would be great and would probably help us catch a lot 
of things.

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

Yup. I've re-tasked #1635 for this.

> a few tweaks here and there that would definitely enhance useability, 
> with the
> main common theme being a consistent way of doing things.

Please do submit enhancement (or bug, as appropriate) tickets for the 
ones that aren't already covered...

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

Probably someone needs to write some LDAP code...

> But, currently, to provide users the ability to change their own 
> passwords, you have to install the passwd module, which implements 
> the Passwd class.

Yes.

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

The idea for a while has been that the Auth drivers should know how to 
handle passwords and be able to change them.

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

Definitely not that one.

> 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

Because we refactor things over time to make more sense. You're looking 
at it while it's in transition. A very slow transition. See the 
pendulum? You're getting sleeeepyyyy....

-chuck

-- 
"But she goes not abroad in search of monsters to destroy." - John 
Quincy Adams