[horde] phpGroupWare + Horde

[Dan Kuykendall]

> 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.

This is sometimes a limitation, but there are still so many php3 users
that we havent felt its worth dropping php3 support just yet. Also Im
not happy with the new php4 license and some sites wont upgrade due to
it. Hopefully this will be worked out, but we have beena bel to do a
surprising amount with php3/php4 compatible code.

> 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.

Understandable

> > 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.

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.

> 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.

LOL. I can see that. I didnt mean it to be rude. I wasnt expecting any
help from the IMP guys on our port. I was only going to port it into
phpGW so that it "worked", because I am very unhappy with our current
email app. Then the SM guys are willing to write SM2, which is a total
re-write, so that it works with phpGW from the ground up. This is why we
would have dumped IMP at that point.

> But let's explore what each side has to offer.
> 
> 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.

Agreed. And this is a good thing, because you guys will think of apps
that we dont, and then we will work to duplicate what we dont have, and
likewise on your side. Our users will all benefit.

> 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?

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.

> 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.

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?

> 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.

You need to look at the cvs code. We are almost completely moved to
ACL's for app permissions. My ACL design works basicly as you are
thinking. There are the acl table entries, and then there is a
acl->check() function which check the acl table for a users rights. It
takes into account the group membership and there are a few overrides.
Example, there is a groupid 0 which is the Everyone group. If there is
an ACL setting for this groupid 0, then the user will have access to it.
And then there is a rights 0 which if set is considered an "explicit
deny" meaning that the check function immediately returns a false
regardless of any other rights the user may get thru group memberships
or whatever. This gives the admin much control.

> > 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?

I nkow of only 5 installs so far. But I imaging this will grow as time
progresses. I personally host phpGW for a few of my clients, which is
why I wrote in the support so that i wouldnt have to install it
seperately for each of my 15 clients.

> 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.

Yes, frames evil, tables good. We havnt gone to sytlesheets yet, but we
might very soon. We have our own "theme" format for the colors and
fonts, which then the templates use.

> 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.

This is easy enough with the templates structure we have. I have been
working on a lynx compatible interface that will probably be the basis
for my WAP compliant one.

> 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.

Our setup prog is very slick if I should say so myself. As soon as I get
the schema_proc code from micheal dean, then I will finish the app
installation support and it will be very very sweet.

> 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.

Agreed. I really didnt know how active Horde was. I am sorry for
offending anyone on this point.

> 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.

I had been under the impression from the docs and other users that it
was pretty decent. Regadrless IMP is still a winner.

> > 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. =)

Oh, I suppose your not "great", but we suck at this.

> 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.

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.

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

Quite possibly, but the thought was to work together to provide a basic
interface for apps to use, to talk with our seperate API's. This may not
be practicle, but we might at least bring the app <-> api interfaces
closer so that apps can be ported between our systems easier.

> 
> -chuck

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.

Seek3r