[horde] Making a project using the Horde framework
Chuck Hagenbuch
chuck at horde.org
Fri Jan 26 08:19:54 PST 2001
Quoting Anil Madhavapeddy <anil at recoil.org>:
> It pretty much just means using the basic 'helper' libraries that Horde
> offers. In the development stream, this means classes to help with logging,
> preferences, browsers, locales, encryption, online-help, session management,
> MIME, and so forth.
There also coding standards and ways that we organize all of our apps. If this
is an intranet application that's never going to be contributed or made public,
that doesn't matter so much, but if it's code that you might make public at
some point, keeping things organized similarly is a good thing to do.
> The current effort is geared towards solidifying the Horde API, so that
> its releases can be totally separate from IMPs. Currently, they are pretty
> tied together. When this happens (which should happen when the 2.3.x
> development release becomes the 2.4 series), the framework should be safe
> to use in your own applications.
In the current development code, the break is pretty good. There are APIs that
could be more robust, but that will come with time.
> Ooh, now you're talking :-) There's been discussion of a common Horde login,
> and Chuck has said it's something he definitely wants in. The idea at the
> moment is that you have a single Horde login, and that stores your credentials
> to IMAP servers, LDAP servers, etc in a secure fashion (probably two-way
> encryption keyed off the Horde password).
Or based on a passphrase that you'd enter to "unlock" your accounts. That'd
probably be a per-site or per-user option (whether or not to store passwords).
> So yes, this is on the cards, but for the future - it isn't there yet.
I'd love some motivation to see it happen sooner rather than later, though. =)
> Excellent! Horde is covered by the GPL, and the modules under the LGPL,
> last I looked.
The API is under the LGPL; all of the current apps are GPL'd, I think, but any
free software license is acceptable.
> Those sound like good books. Best advice is just to dig in, and ask lots
> of questions ;) Good luck!
Yes. I'd recommend joining dev at lists.horde.org, if you haven't already, since
that's where development discussions take place.
You can also get a taste of some API documentation for the current Horde stuff
at: http://chuck.bitgroup.com/api/ - it's a bunch of javadoc-style docs
generated from our current classes.
And I'll reiterate what Anil said about asking lots of questions - I want Horde
to be a framework that people can pick up and build something out of pretty
easily. Anything that doesn't make sense is either something we need to
document or need to work on. I'm not promising the learning curve will be easy
the first time, but I'm committed to making it easier as it goes along. =)
-chuck
--
Charles Hagenbuch, <chuck at horde.org>
Entropy. It's what's for dinner.
More information about the horde
mailing list