Sunday, May 29. 2011Is it really that hard?
It's 2011. Computers are here for a couple of decades now, but they still don't help me with the most simple problems. I've been asked once again about a recommendation for a GroupWare and still don't know what to say. This are the simple requirements:
Manage my Mails, Calendar, Contacts, Files, Knowledge (Wiki) and ToDos (including IssueTracker). Let me synchronize these informations with mobile devices and for offline work. Allow collaboration and sharing. I started professional programming in 2006 with the eGroupWare project, which provides the above functionality more or less, but I still can't recommend it. Neither could I recommend any other system I know of (Tine 2.0, OpenGroupWare, OpenExchange, Horde, Kolab, ...?) since they violate one or more of my secondary requirements:
This kind of software is on the top position on my Things-To-Do-When-I-Have-Time. But on the other hand I know that many have already started such projects and either they did not deliver sufficient functionality or there code base is a PITA. Yes, I'm ranting once again. But please show me a decent GroupWare and I'll praise you on any occassion! Or should I make this my project for my bachelor thesis: A Contacts+Mail server/web frontend in Scala using CouchDB, Dovecot? What do you think? Trackbacks
No Trackbacks
Comments
I think an interesting point here is that you can power most of this system just with Google. Mail, calendar, contacts, and files (Disclaimer here I'm sure: Your pretty much limited to office docs) are all easy to handle in gmail / gcal / gdocs, and as such will sync to any moblie device. Add to this you have access to them through fairly decent APIs I think they are a winner for this type of project. On top of this using google apps you could power the user system with google as well. That would be the largest chunk of your application.
As a side note though, on your points, I think your missing a very large point. Any code base that isn't written properly isn't going to be maintainable regardless of the language its written in. PHP, Ruby, Java, any of them. Bad/Lazy coders === bad, unmaintainable code. And as far as relational databases its pretty much the same point. If you don't know how to properly design the database you will run into all kinds of problems. There is no reason a relational database couldn't handle this sort of task.
If you do decide to reinvent groupware, please learn from what Facebook does for shared calendaring, contacts management and remote access. And that's before we mention ease-of-use which helps get me to add your software to my life in the first place. With groupware, the network effect or ease of adoption are position 1 or position 0 in the priority list: no-one gains if my public calendar is in a format they can't read, or can't invite me to events.
But the final words have to go to Netscape legend Jamie Wazinski at http://www.jwz.org/doc/groupware.html. (It's probable you know this text, but maybe you don't...) K3n.
Gnus + Org-mode does most of what you need.
I use Org-mode to publish a .ics calendar, for instance, based upon my appointments which are mostly created from e-mails.
…the org-mode does not supply the server-side components. It also requires emacs, which is not feasible for everyone.
Sorry to sound so acid but yours seems just too much as another bright boy reinventing the wheel.
"a maintainable code base (this rules out PHP IMHO)" It doesn't. While Sturgeon's law is of application here, well, Sturgeon's law is of application everywhere else. A PHP codebase should make you heavily suspicious but it certainly doesn't rule out PHP: proper code can still be written in PHP. "no relational database!" Stupid nonsense. Are you really so young to be fed with the "nosql" coolaid without hesitation? groupware is basically relational data. "they're just not made for this kind of data or why do you think system X allows only for N numbers of mails/addresses/phone numbers per contact?" re-read yourself. I'm sure you are not really that stupid. "no dependency on antique technology (yes, I mean Kolab depending on Cyrus)" Yes. You are really such a youngster. Let's imagine you go with your uberperfect groupware system. Let's say it's so perfect it becomes the 'de facto' groupware system for everybody. What do you think that will happen? Yes: by the very fact of being a widely used system it will become based on "antique technology". As a matter of fact, what's so revolutionary on a groupware system not to be based on ancilliary technologies? "easy installation at least for test setups" Re-reading your post I'm betting "easy" is starting to mean "easy as in I don't really know the ways of my preceding greybacks, so I'll declare 'hard' to be anything I haven't time to learn or seems not being cool enough".
You might have sounded less acidly if you actually made the effort and would have read the article you're commenting on.
Were you not projecting your idea of what was written into the actual text, you'd not make yourself sound so foolish. «no relational database» doesn't necessarily mean nosql; it might as well mean LDAP (object-oriented store is definitely more useful for something like contact data), «cyrus is ancient», might not mean anything that exactly that: it's ancient, especially when you compare it to dovecot …and I've yet to see a huge and maintainable PHP codebase. (a side note: your patronising and condescending attitude does not help and provokes similar patronising and condescending replies; thankfully I'm not that easily jaded into that terrible behaviour)
I'm sick about this constant trend of bashing Cyrus in favor of Dovecot. Dovecot appears to be good and working OK for many users, but when I tried to move to Dovecot (trying to follow the trend I'm talking about), I:
1) Found its idea about maintaining virtual mailboxes to be confusing at best. 2) Found its idea about making LDAP auth work with virtual mailboxes to be confusing at best. 3) Reported two problems with LDAP authentication (we're using "enterprisey" setup, involving Windows domain) which are not fixed to this day. Solving problem (2) required getting help from the mailing list, (3) took me a couple of days for debugging and reporting. All the things mentioned above "just fscking work" with Cyrus with no effort at all. So please stop claiming Cyrus is ancient without presenting at least some list of facts rather than muttering marketing-style empty slogans.
I'm very satisfied with Cyrus IMAP as a user/administrator. I'm curious to know how or why Dovecot is better, though. Surely it's not because it's not "antique"?
(I thought antiques were highly valued because of they were built with craftsmanship that's stood the test of time)  -Eugene
Citadel? http://www.citadel.org/doku.php
I've never used it, but off the top of my head, I think it can meet your criteria:
I believe Liferay's default setup satisfies all your requirements except mobile interface/sync and no-relational database.
http://www.liferay.com/products/liferay-portal/overview
"a maintainable code base (this rules out PHP IMHO)"
Just because you can't write maintainable PHP doesn't mean that all PHP is unmaintainable. Good OO design speaks all languages.
I would personally prefer that for each of the common groupware components several high quality, interchangable components would be available that connect together using open standards.
This means: - a wiki solution - a ticket tracker - a webmail client - a mail server - an IMAP store - a calendar web interface - a calendar store - etc... For most of the above good solutions are available and can be combined (e.g. postfix+dovecot+squirrelmail or exim+courier+horde, etc.). If each of these has a nice, replacable component (calendar is a bit hard still) you can build the system you prefer.
"this rules out PHP IMHO"
Since you're such a bigshot Java developer now, why are you still sending your posts to Planet PHP? Are you just trolling?
I thought the planet-php people would have removed my blog by now. I looked it up now and I'm indeed still listed at planet-php.org.
It's worth pointing out that both Exchange and Notes possess none of the attributes you find desirable, in fact, they possess exactly the opposite attributes. Yet, they dominate the marketplace and make their creators tons of money. You really should think long and hard about that.
QUOTE: no relational database! they're just not made for this kind of data or why do you think system X allows only for N numbers of mails/addresses/phone numbers per contact? If you actually believe this then you don't understand relational databases enough to be talking about them, and you certainly don't understand data persistence enough to even think about undertaking this task. Building a table to allow unlimited (up to the size of the database) addresses per contacts is relational database 101. In fact, all of the limitations in Exchange that I can think of are definitely related to underlying database limitations. Some of them are fairly ugly (e.g., the old limitations on distribution list size) but I'm having a hard time thinking of any that weren't directly related to an ESE limitation somehow. There obviously may be some, but it's very arrogant to assume these limitations are due to the representation of data used by the DBMS. I can think of many potential reasons for avoiding an RDBMS (in whole or part) as part of a groupware solution, but the reason you stated is not one of them. The reality is such a product is inherently a multi-database solution.
uw-imapd please
 And no dependency on external services, like evil Google’s. Other than that… I don’t particularily care about the DBMS, but it should be written in a legible language (I am not fond of PHP, but it’s more maintainable than, for example, Ruby) and be a-g i’ble on Debian. Oh, and: it needs a desktop client, not just a web client and mobile sync. Kolab works with kdepim… but it’s “fun” (reads: buggy). Others aren’t better. And Cyrus is a catastrophe.
Obviously you dont know what Cyrus is today.
Cyrus is under active development with a very strong and active community. Cyrus 2.4 is fast and stable. http://www.cyrusimap.org/ Stop the FUD ! |
|
|
|
