[dev] IMSP Backend for Turba / Horde

Chuck Hagenbuch chuck at horde.org
Thu Jan 22 18:38:57 PST 2004


Quoting Michael Rubinsky <mike at theupstairsroom.com>:

> As it is written now, I have all the IMSP driver code in  turba/lib/Driver
> and I added preferences to Turba to allow the user to use a different
> name/password for the IMSP server if needed.  Everything works well like
> this.  However, I was thinking of adding a horde preferences driver for an
> IMSP back-end as well.  My question is, would it make more sense from a
> design standpoint for me to put all of the 'core' IMSP library code inside
> the horde framework  (maybe even separating out the IMSP server
> authentication code and putting that into framework/Auth) and changing the
> drivers to include the code from there?  That way, it would be easier for
> someone to do something like  add a new authentication method to the IMSP
> code. (Right now, I only have plaintext and CRAM-MD5 written).  If this is
> the case, I would also move the 'alternate login' preferences I added to
> turba to horde.  Maybe under the 'Remote Servers' option group?

Here's what I'd suggest in terms of classes:

- A Net_IMSP class that provides an API to the protocol. This would be a package
in framework/.

Then, 3 classes that'd use the new package:

- An Auth_imsp driver that would be added to the Auth package.

- A Prefs_imsp driver that'd be added to the Prefs package.

- A Turba_Driver_imsp class that'd be added to Turba.


How's that sound?

I'm not sure what to do about the passwords stuff, though. I'm interested in
thoughts from others on that one...

> Of course, I will make all these additions available to the project...if
> anyone is interested that is!

Definitely interested. :)

-chuck

--
Charles Hagenbuch, <chuck at horde.org>
"Here, I brought some cole slaw. It's made from peeeooople! Just kidding."


More information about the dev mailing list