[horde] phpGroupWare + Horde

[Chuck Hagenbuch]

Quoting Dan Kuykendall <dan at kuykendall.org>:

> Any hope of a merger between our two projects? or the the consensus to
> keep each other on our toes?

I'm always in favor of sharing code where possible. However, I see some 
barriers to Horde and phpGroupWare doing this.

1. You require php3 compatibility.

>From your message, it sounds like you might be looking at IMP 2.2. This isn't 
our current development version; it's only being maintained for security fixes 
and minor updates at this point. The development code - Horde, IMP, and all of 
the apps in cvs - has all been updated to take advantage of the new features of 
php4. This includes session management, better OO features, a bunch of 
miscellaneous functions/updates, and the PEAR class library.

If at some point phpGroupWare moves to php4, I think it would be very 
worthwhile to maintain a set of PEAR libraries between us - and any other 
similar projects - for common operations that can be abstracted between us. The 
Log:: framework that we donated to PEAR is a good example, I think.

> There is a ton of duplicate code between the two projects, and both have
> their strong points.

There certainly seems to be duplicated functionality, but whether or not code 
is duplicated is a little less clear. phpGroupWare assumes the availability of 
a SQL database, for contacts, calendars, etc. We use an abstracted interface in 
our calendar program; currently it uses the mcal library, but it could be 
adapted to pretty much anything. The contact manager that is in the works 
already speaks LDAP and SQL; other backends are just a matter of writing the 
driver. And so on. The approach between the two projects is rather different.

> Horde has IMP which is hands down the best webmail
> client I have seen. I am looking to create a fork of IMP to toss into
> phpGW and replace our current mail client. The SquirrelMail guys are
> looking to write their SM2 so that it plugs directly into phpGW, and at
> that point depending on which is better, it will replace our IMP port.

The wording of this paragraph - "we'd like to take your code, use it a bit, and 
then probably throw it out" - doesn't do much to get us off to a good start. 
But let's explore what each side has to offer.

> 1) More add-on apps: phpGW has more add-on apps, but not all apps are
> stable. I still think phpGW wins on this account because the apps will
> mature and most are fairly active.

I will certainly agree that right now phpGW has more apps listed, but I'm not 
sure you've looked at everything that we have in CVS, and I call it a draw 
since neither of us is going to stop maturing in time. But that's not really 
relevant to whether or not we can work together.

> 2) Better infrastructure for application interaction: Via our "hooks"
> functions and our Object Factory applications can easily use resources
> from other apps or hook themselves into certain areas of other
> applications.

This I'm very curious about. A look through your code (the latest tarball 
available from sourceforge) and your developer documentation 
(http://www.phpgroupware.org/phpgroupware/phpgwapi/doc/) didn't tell me 
anything about how to go about using this. Can you elaborate?

We have a Registry:: class in Horde 1.3 that performs what sounds like a 
similar function, but it could be a lot better and I'm looking for ways to 
improve it.

> 3) Security System: We an ACL security system which is extremely
> flexible and gives admins complete control of their installations, and
> very soon will allow for giving rights to other users so they can admin
> certain apps, or admin the rights that their subordinates have.

>From looking at your code (phpgw_accounts_*.inc.php), it seems that permissions 
are tightly tied to user account info? Permissions are certainly something that 
Horde needs for a number of things to go forward, but I was thinking of 
implementing them as more tied to objects - ie, you give permissions to an 
object, instead of to the user. More role-based, I guess.

> 4) Multi-domain support: Via a single of the code phpGW can support
> multiple "domains" (using separate db's). This is mostly useful for
> companies tat want to host phpGW as a service. 

Check. Do you have a lot of people asking for/using this?

> 5) Multiple interfaces: We have almost completely moved to templates for
> the interface and we designed our template system to allow for any
> number of template sets so that the interface can be easily customized.
> So far we have 3 different interfaces with one more on the way. Pretty
> much gives phpGW a "skins" system, which our users really like.

Heh heh. We're in the process of simplifying our user interface - from frames 
to no frames - and recent discussion has confirmed that this is a good 
direction for us to go in. All of the colors and fonts are seperated out into 
stylesheets, and that's probably as far as we're going to go in that direction.

However, if you have a way of easily switching from a web interface to a wap 
interface, for example, that's something to talk about.

> 6) Better setup program: I think that phpGW's setup program is much
> stronger, and will be even stronger yet when our new schema_proc code is
> done. The schema_proc code handles all table creation and upgrades using
> an abstraction layer along the lines of what the phplib db classes does
> for handling queries. So once schema_proc is in place, all apps will
> basically be db independent and can be run by any db that we have create
> a schema_proc class for. 

We don't really have any setup program for the development code right now. I'm 
sure someone will ask for one, eventually, but no one has yet.

> 7) Very active: phpGW is a very active project and we have lots of
> excited developers and users involved. I am just now joining the horde
> mailing lists, but I had the impression that horde was not very active
> anymore.

This has been beaten to death already, but again, Horde has been very active 
recently. Once in a while we have slumps - people get busy - but we've survived 
for years now with things never really slowing down, even if we don't always 
move forward at a lightning speed.

> 3) Strong apps: Apps like IMP and Jonah are very slick. I haven't
> reviewed any other apps in detail, but these two are stand out
> applications. IMP is the single best webmail I have ever seen.

To be perfectly honest, Jonah has never yet been at a stage that I'd consider a 
releasable "application". An interesting bit of code, sure, and I have hopes 
for it to reach the application stage, but it's not there yet.

> 4) Better app websites: You guys advertise your add-on apps much much
> better than we do. We just have code in cvs, but no websites or detailed
> information on them. This is something we need to do, but you have
> already done. Kudos

Thanks. I thought we were pretty bad about this, actually. =)

> I would be very excited to broker some kind of merger in our efforts so
> that between the two projects we can either do a complete merger, or to
> possibly work our some "compatibility layer" so that add-on apps written
> for one, could be used in the other. I do believe the phpgwAPI to have
> serious advantages to the Horde base, but do think you have applications
> that are fantastic. It also appears that your coding style is a bit
> different than ours, and I will have to study yours to determine which
> is the better solution.

I think the style is perhaps a larger difference than you think. I'm also 
curious if you see advantages to the phpGW API that you didn't list above? 
Feedback is always good.

How would you envision a compatibility layer working? That sounds like a 
nightmare, honestly, at the very least in terms of performance.

> Regardless, I wish you luck and if no merger ever takes place, then I
> hope we can have a very friendly competition to create the best possible
> groupware system!
> 
> Seek3r (aka Dan Kuykendall)
> phpGroupWare Project Leader
> 
> -- 
> Horde mailing list: http://horde.org/horde/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: horde-unsubscribe at lists.horde.org
> 
> 



-chuck

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