[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