[horde] phpGroupWare + Horde

[Chuck Hagenbuch]

Quoting Dan Kuykendall <dan at kuykendall.org>:

> Most of our code is abstracted. Addressbook class for LDAP is almost
> done, and the calendar is one of the last to be moved to full data
> abstraction. So this isnt as big a problem as you might have thought.
> I think our approach is similair, but we started out by taking
> webcalendar and integrating it. We have now been going back and
> abstracting the data interface. So in the end the concept ends up the
> same.

Okay. This may be personal bias shining through; to be perfectly honest, I just 
get a "cleaner" feeling looking at the way our stuff is abstracted than yours. 
*shrug* It might not be based on anything.

> My docs suck. I have been hacking code furiously and havent stepped back
> and documented everything. I will be doing that tho. I will see if I can
> write out some explaination of how our stuff works. Right now the only
> developers to be making use of this stuff is the ones that talk with me
> directly.

Can you just point me at an example of it in the code?

> I will take a look at this Registry:: class. We have a multi-dimensional
> array that we use for all the config settings, but a registry class
> sounds interesting. We seem to come at the problem from different
> directions, but we might be able to merge the main features in some way.
> I will certainly look at this class you mention. Also, is it well
> documented so that I can understand it quickly? or would you be willing
> to sit down with me and run thru it?

There's phpdoc documentation for it (I'd give you a link, but phpdoc is 
currently broken ...); it's not really clean enough that it's worth documenting 
just yet.

> Its a very modular system. I know yours is as well, and your PEAR
> support is nice. I think that our basic API design is fairly clear and
> flexible. For example I am in the middle of writing a mini-phpgwAPI that
> add-on apps can use so that they can distribute their app as a
> standalone app without having to do major code forking. They would just
> include this min-phpgwAPI which has only the barest functions nessesary
> and most functions are just dummy functions. Our API design also makes
> it very easy to swap out classes that are well defined, with ones that
> work however you want. Example is our auth class, we have auth classes
> for sql, ldap, http_auth, imap_auth and soon will have one for x509
> auth. This is only an example, but its how we think out the whole API.

To be honest, I'm not seeing major advantages here. Am I missing something?

> Thank you very much for taking the time to discuss the details. It does
> appear that there is a large bridge that would prevent our projects from
> really merging, but an open and frank dialog will help both projects.
> No flame, no bashing, just technical discussions. Maybe some such as
> iCal/vCard support, and testing said support for addressbook and meeting
> request interaction.

That sounds like a good project. Is there a standard for sending contact 
info/meeting requests as some kind of MIME attachment to an email?

-chuck

--
Charles Hagenbuch, <chuck at horde.org>
Entropy. It's what's for dinner.