Focus on Infusion

A few days ago, Infusion
(screenshots)
was announced on apps.kde.com. Along with Citadel/UX serving as backend, Infusion aspires to compete with
the likes of Aethera, Magellan, Evolution, and yes, Microsoft Outlook+Exchange. Is
Infusion there yet? Nope. But from what I've seen, I've certainly
been impressed by Citadel/UX, and once
I managed to get Infusion compiled, I was able to enjoy some neat
functionality. Coupled with the enthusiam of author Brian Ledbetter, it would seem that Infusion is
going places. Read on for further details of my Infusion experience
and for an interesting interview with the author. Update: 06/16 03:30 AM by N: Art wrote in with some interesting comments on the upcoming version(s) of Citadel.

A Little Test Drive

Most of the packages I needed to
compile Citadel+Infusion were readily available with the Mandrake 8.0 Standard
Edition, with the exception of of libical which I obtained from rpmfind.net. Unfortunately, the
build experience itself left something to be desired with less than optimal
configure scripts and minor source bugs. No doubt the problematic
compiler from Red Hat 7.x included with Mandrake 8.0 also had a hand
in the matter. After several source and makefile "adjustments"
however, I managed to get Citadel, libCxClient and Infusion all
installed and working. Despite all this, I should note that my efforts were nothing compared to the pain and tragedy I've witnessed fellow colleagues go through while installing (or re-installing) Exchange -- things can only get better from here.

Citadel/UX's BBS roots are almost immediately apparent, although the
setup is fairly painless to a seasoned Unix user. Simply run the setup
script, create a sysop account, login and then create the basic
configuration. A good idea at this point is to create a couple of
test users for Infusion.

Citadel/UX is pretty impressive, including such things as SMTP and POP
servers in the package. Citadel can send mail between local users,
send and receive internet mail, and make mail available to internet
users. This brilliant arrangement means that, as far as mail is concerned, any
diehard Mutt user such as myself
can happily coexist on a Citadel/UX network with Infusion users. Brian had a good idea when he chose to base
Infusion on Citadel/UX. One might even ask why other Open Source
projects such as Aethera and Evolution don't
consider improving and sharing this capable backend.

I was able to test basic Infusion functionality with 2 test users. I could mail back and forth, I could send mail to an internet account, I could receive internet mail, and I could view shared areas. Infusion also has chat capabilities and token organizer/notes functionality which I did not fully investigate. Infusion is evidently here both in concept and proof-of-concept, including the expected bugs. The colourful interface will surely evolve to please many in the future.

So should you rush out and download Infusion? No. Set your expectations
too high, and you will be disappointed. Infusion is still at
the early stages, but if you enjoy tinkering, or you're a developer
who can help, or you or your company has an interest in collaboration
systems, then check this out.

Want more? There's more. Get the facts below from author Brian
Ledbetter who was kind enough to answer a few questions.

Talking To The Author

How robust is Infusion/Citadel, and what kind of environment have
you used it it in?

Infusion by itself is actually not a very capable application, and is
still in the early stages of development. Right now, Infusion is tied
in to the Citadel/UX backend 100%, kinda like how most of the
components in Microsoft Outlook are only useful with an Exchange
server in the backend. I envision the ability to add plug-ins for
SMTP/IMAP/etc. ala Outlook sometime in the future, however.

The Citadel/UX Communications Server is a promising platform.
While many of the newest features are still in the development stage,
it is currently a rather powerful communications platform. It's had
over 10 years (actually, almost 25 years, if you count the old
non-UNIX variants) of development behind it. There are sites
currently running Citadel/UX which have thousands of users, with a
large number (I'm probably not the best person to ask here) of
concurrent users accessing the system.

How does Infusion compete with Microsoft Outlook/Exchange,
Aethera/Magellan/KMail, Evolution etc.

Infusion is a direct competitor of any MUA (mail-user-agent), though
due to how early in development I am, it's not all that capable yet.
Specifically, Infusion is aimed at competing directly with other
group-scheduling packages, such as Microsoft Outlook and Evolution.

The Citadel/UX server is aimed at offering a powerful group-scheduling
or internet service server similar to Microsoft Exchange Server. The
maintainer of this project is Art J. Cancro; see the Citadel/UX webpage
for more information.

Do you see Infusion/Citadel being used to communicate
cross-platform and with other (possibly non-Citadel) clients?

Any client can access a Citadel/UX server via a standardized library,
libCxClient, which will soon be a part of the official Citadel/UX
project (I'm maintaining it until then). Also, end-users can access
Citadel/UX through standardized protocols -- It communicates via SMTP
and POP3, currently, with full IMAP support on the way.

Like I have said, I plan on adding 'hooks' to Infusion to allow it to
communicate with other backend servers. This is still on the
drawing-board only, though.

I've been given to understand that Infusion currently shares some
code with other KDE apps such as KOrganizer or KNotes. What are your
plans for future integration with the rest of KDE?

Infusion currently shares some code with KOrganizer, but after
discussions with the head of the KOrganizer project, Cornelius
Schumacher, I will be stripping the code out and utilizing the KParts
API exported by KOrganizer instead. This way, we have a standardized
KDE calendaring component, without having to maintain two seperate
portions of code.

As far as the notes go, Infusion has only native-code, with me referencing
the KNotes source for hints. :)

What previous development experience have you had? Why did you
start this project? Have you been doing this project in your spare
time? What were your experiences while developing for KDE/Qt?

Actually, Infusion is my first try at writing a GUI-based application.
The KDE libraries have made this much easier than I ever thought it
could've been, even without using tools like KDevelop.

As far as past experience, I've not really done anything of note in
the open source world. I've been working in the software industry for
about 5 years now (mostly web application development, which, after
writing real software, doesn't seem all that impressive ;).
I've worked for a few companies during this timeframe, though my
employment has generally gravitated towards web software development.

The Infusion project is currently done entirely in my spare time, what
little bit of it I have. According to my CVS logs, which vaguely
resemble my memory, Infusion was first checked in on November 17,
2000. It's gone through quite a few changes since then. I hope that
before too long, it can prove to be a valuable addition to any
enterprise seeking an affordable groupware platform. I certainly hope
to use this project to prove undoubtably that UNIX can be as
user-friendly as it is powerful.

Anything else you'd like to add/comment on?

KDE rocks! If I were to try developing Infusion in GTK (I did, actually, but scrapped it
almost immediately after beginning), it would've taken twice as long
as it has, and it would've been substantially larger. I would like to
offer my sincerest and most gracious thank you to all of the
KDE developers out there, who have given us such a wonderful
development (and user) environment for UNIX!

Dot Categories: 

Comments

by Chad Kitching (not verified)

"First off, it has a clearly defined, open API for plugins. [...] look like this functionality was designed from the start [...]"

Now this is interesting. Indeed this could be a very powerful feature and "selling point". I'd really be interested to know if they've defined a mail provider interface (much like Outlook uses MAPI providers), and if it's simple and generic enough to be [re]used by other mail applications. There are obviously PIM/groupware servers in the work (such as the Citadel/UX mentioned in the article), and if a fairly common API can be defined, programs could use it as a sort of plugin for non-integrated mail services. I have a feeling more and more servers will eventually pop-up that don't use IMAP or POP3 as their native protocol, or have features that can't be implemented in those protocols, and it'd be nice if the server creators could make a single shared library that could plug into all these different mail clients and just work independantly of toolkit, desktop or anything else.

"The thing that seems to really seperate it from the other PIMs is a nebulous thing that I freely admit that I don't quite understand."

Looks like it's what their website calls PDR... I don't quite get it, either. It'll probably be one of those things that you don't understand what's so great about it until you start using and relying on it.

My problem in all of this was we had two people complaining that their program was not a clone and everyone else's was. I think this is a dangerous attitude to have, especially when you're developing a program. It can seriously blind you to limitations in your program that your "competitions" program doesn't suffer from. Whether any of these programs are a clone of Outlook isn't as important as how well it will do the job it's been designed for.

It will certainly be interesting to see how all the projects evolve over the next year or so. I'm glad someone finally can tell me what differentiates it from the competition other than "look". At least they're all trying to break new ground, Aethera with those plugins and "PDR", Evolution with it's VFolders, and now Infusion with it's support of Citadel/UX. Although, now I'm interested in what's unique about Magellan, despite the fact that they seem to be either way behind schedule, or too busy to work on it (or maybe still bitter that theKompany forked magellan to make Aethera?).

by Tackat (not verified)

No, actually it seems to me that he is trying to correct some statements you made in a public forum and he does it in a quite reasonable voice. This is certainly not what trolling is about. As long as he does that in a reasonable manner without flooding the forum with his opinion you have no right to call him out.

I think before you try to do any further "advocacy" for KDE, theKompany etc. you might want to read

Advocacy.html

which is not only true for Linux but to a certain degree also for KDE.
You might especially be interested in "6. Canons of Conduct" ... which says:
"Avoid hyperbole and unsubstantiated claims at all costs. It's unprofessional and will result in unproductive discussions." e.g.

Tackat

by Craig Black (not verified)

[ADMIN: Please do not reply further to this thread]

Well the dot right now is crawling with closet and open gnome supporters that are trying direct discussion and spread miss information. I'm getting sick of it. Even anon of linux today fame for trolling openly and often against kde feels comfortable doing gnome advocacy here on the dot. Its getting hard to tell who's here to add something or push discussion and options away from what's best for kde. Kdes pulling so far ahead of gnome among user there resorting to less than ethical tactics.

Craig

by ik (not verified)

you see non-existant phantoms (don't know if this is right English). Maybe there are gnome users criticising kde on this forum, but why not ? kde ain't perfect yet ... and posts like "this is bad, i don't like the way thats' done because ..." help making kde better. if they spread misinformation, simply correct it.

by jj (not verified)

I disagree. There are definitely more trolls here now than there were a few months ago (I am not saying that these troll are Gnome supporters, to make that clear). But if you really do not care for the other environment, then you should stay away from their discussionboards.

by advocates are boring (not verified)

> Well the dot right now is crawling with closet > and open gnome supporters that are trying
> direct discussion and spread miss
> information.

And how exactly is this claimed trolling different from what you were doing on Gnotices a week or two ago?

by Craig Black (not verified)

[ADMIN: Please do not reply further to this thread]

Well advocates are boring. I'm assumeing that is your real name. I was promoting a desktop web poll on gnotices to make it fair. I pushed it here and on gnotices. In the end with over 4000 votes which were verified as good my the sites owner kde had a 9 to 1 margin over gnome. He finally had to drop the poll because someone tried to run a script to push up the gnome votes. It would have be fair if i just mentioned the poll here now would it? I wanted to know with as much accuracy as i could what the desktop user base was. I'm not saying kde has that big of lead though. There was another poll on www.freeos.com with over 1600 votes where KDE only got 57% and gnome came in at 19%. Which is a bit different. Thats was a bit more of a geek crowd however because the command line came in at 13% with 221.

Craig

by advocates are boring (not verified)

[ADMIN: Please do not reply further to this thread]

That's all you were doing, eh? I'll just provide a few choice quotes and let the public decide.

craig: "Well i sent it here and the dot and linux today. It's not rigged i think the kde users are more
enthusiastic than gnome users or there are more kde users. Thats the fact." (gnome-news1)

craig: "That was then this is now. Kde has been moving at a much faster clip than gnome has.
Since xiamian took over most of the development and kde stayed a hacker desktop i think that
there has been many defecters to kde including me."
(gnome-news2)

craig: "Ah well this gnome defector will stay where the action is at kde. Were there is no
xiamian or eazel just hackers" (same thread)

craig: "Kde has pulled so far ahead of gnome and the fact that kde id still a hacker afair has
made all the difference. The eazel thing and xiamian deal has really screwed gnome over.
Mean while kde pulls way ahead in developement and user base.
Its no longer a 50 50 affair."
(gnome-news3)

That all says TROLL to me.

by Navindra Umanee (not verified)

[Please do not reply to this message. Mail me directly for comments.]

I think it is a given that Craig is what he is. This has been on enough forums for enough times. The public has to decide nothing, and certainly not here on dot.kde.org.

Please stop this bullsh*t, we will use IP banning if forced to do so. Feel free to use our free-for-all trollfest forum meanwhile.

by Craig Black (not verified)

Well showing one side of a converation is not a fair account of the conversation. I'm always a advocate and was very impressed my the gnome folks persistance in defending there project. The kde folks could learn a thing or two. But i was not purposely trolling i was inviteing them to the poll which spured a lively debate. The difference is i was not pretending to be something that i was'nt. Here i fear there are those that are not open with there motives.

Craig

by Daniel Remsburg (not verified)

C'mon, this is lame. You don't understand that the fact that this is his personal project. This isn't your project for you to criticize. He stated it was his first GUI app. Who cares what it looks like. Maybe you have to build a wheel before you can make a good one huh? Well basicly, you won't have to worry about 'rebuilding the wheel'. Pretty soon all the good ideas will play out and there will either be a victor, a collaboration, or a totally new program that'll combine the features of all of 'em together that will take the cake. Just like it sucks to keep re-inventing the car, i'd sure hate to be forced to drive a Ford because that's the only car (because they didnt want to re-invent the car). Some diversity is good, and I'm sure he didn't re-invent the inner workings which makes a mail program work. I'm very sure he just used the code from any standard mail program, which is what OSS is inteded for. No the whole damn project, just a bit of code here and there :^)
[email protected]

by Evandro (not verified)

"No doubt the problematic compiler from Red Hat 7.x included with Mandrake 8.0 also had a hand in the matter."

the problem is in infusion itself, not in the compiler.

"Most of gcc 2.96's perceived "bugs" are actually broken code that older gccs accepted because they were not standards compliant - or, using an alternative term to express the same thing, buggy."

by Navindra Umanee (not verified)

Well, my personal grudge against Mandrake 8.0's compiler is that it pretty much breaks SableVM. One of the compiler bugs can be worked around by turning off GCC optimization, but the other one related to native interfaces doesn't seem trivial to work around.

This basically means that Mandrake is useless as a development platform to me, and for real work, I have to use some other platform or install a good compiler. So I'm quite happy to bash this compiler decision whenever I get the chance, and it's also quite possible I might have jumped the gun here. :)

-N.

by me (not verified)

while you're at it, when will we be able to post html again? seems like you can *grin*

by Carlos Rodrigues (not verified)

I guess gcc 3.0 will also be useless as a development platform for you since it behaves just like gcc 2.96 relating source level compatibility. If your code breaks gcc 2.96 it will break gcc 3.0.

by Navindra Umanee (not verified)

Oh yeah? And if I turn off optimization flags it will compile certain things as opposed to when I turn them on (stuff that works on the stable version)? How comforting.

Sigh. Why aren't they fixing this? And how do you know they aren't going to fix this?

by Carlos Rodrigues (not verified)

2.96 probably does more optimizations to the code than the stable version.
If those problems are compiler bugs, I'm sure they will fix them (they should). But nonoptimized/optimized code problems do not always mean compiler bugs, optimizations could just show bugs in the code that otherwise go unnoticed. Don't just go ahead and say it's the compiler's fault.
I'm not saying that 2.96 that comes with RedHat is the best thing since sliced bread but it's not as bad as people say it is, I think it is rather good (for a stabilized cvs snapshot anyway, but I would also say it's better than the 2.95.x series), after all, they compiled a whole distribution with it including the kernel (and the kernel is well known to break some compilers, mostly due to kernel bugs but sometimes due to compiler bugs).

by Navindra Umanee (not verified)

Instead of the hand-waving, I respectfully suggest you check out SableVM yourself and the compilation errors first hand -- try to fix them even. I gave you the link in the original comment. :-)

I don't know about Red Hat though. I'm using Mandrake 8.0 which I presume took the broken compiler from Red Hat. Because that's what they do.

by A Sad Person (not verified)

Well, in my experience LM8.0 gcc is better than LM7.2 one, which would crash fequently when compiling KDE.
This used to be quite frustrating - since building it takes quite long already, but of course the rewards are quite big - the KDE developers code very fast ;-)

No such problem with LM8.0 gcc - BTW, have you tried the latest builds from Cooker? Those have some additional bugfixes which may just end up relevant.

by Navindra Umanee (not verified)

Hmmm, I didn't use 7.2 very long (2-3 weeks) before I upgraded to 8.0 but I didn't have any problems with the compiler, and at least it compiled SableVM so I could do my work.

Haven't checked Cooker, thanks for the tip. It's probably easier for me to go backwards to a stable platform though. :(

Cheers,
Navin.

by Carbon (not verified)

>"Most of gcc 2.96's perceived "bugs" are actually broken code that older gccs accepted because they were not standards compliant"

When something worked before, and now it's broken, I call that adding bugs, not removing them :-)

Seriously though, although being standards compliant is good, especially for porting to other compilers or architectures, it's the compilers job to compile as well as possible, even if that means accepting code that is written uncleanly.

by Chad Kitching (not verified)

GCC 2.96 in RedHat 7.x and Mandrake 8.0 in general is a Bad Thing. Both of these platforms are commonly used as a development platform for commercial applications. Because of the fact the C++ ABI in GCC 2.96 is different from GCC 2.95 and will be different from even GCC 3.0, this should make RH7.x unsuitable as a commercial development platform, because you end up locking yourself to that platform and that platform alone. If you were developing GTK apps, this is unlikely to cause a problem, but for QT and other C++ apps, this can be the difference from your program working everywhere and it working nowhere but RH7.x...
Those who focus on the inability of GCC 2.96 to compile their favorite app as a sign of it's bugginess are wrong to blame the compiler. The C++ ABI changes are the reason why 2.96 should not be used (even a 2.95.4 pre-release version would've been a better idea).

by Guillaume Laurent (not verified)

> The C++ ABI changes are the reason why 2.96 should not be used

ABI compatibility problems are just a fact of life in C++ development. If you release binary packages, you just release one for each kind of compiler your customer uses, there is no "locking in". All software vendors do that.

by thierry (not verified)

>If you release binary packages, you just release one for each kind of compiler your customer uses
>All software vendors do that.

Yes, and each new incompatible platform have a price !!

Ok Redhat 7.x (gcc 2.96) have binary incompatibility with GCC 2.95
But if there is another binary incompatibility between 2.96 and 3.0
You end with 3 incompatible version of redhat in 10 month => No professional

Today I prefer the way Suse manage this problem.

by Guillaume Laurent (not verified)

> You end with 3 incompatible version of redhat in 10 month

Assuming that gcc 3.0 is immediately used by RH as soon as it's out, which is quite unlikely to say the least.

Plus at the time they took the decision to use gcc 2.96, there was no telling when 3.0 would come out.

by Is Magellan dead !! (not verified)

Are there developers working one Magellan it looks like the project is dead !!

by zoneur fou (not verified)

... it does news and mail and with little lisp hacking will make either a calendar or mailbox metaphor for all your ICAL standard appointments ....

Switch to gnus now

by John (not verified)

... it does addition, subtraction, multiplication and division. It also comes in a range of sizes an colours, and can even fit in your pocket.

Switch to an abacus now.

by Julien (not verified)

Hi John,
so where can you buy one and instructions on how to use this abacus (for divisions and multiplications especially...)

by Nikki S. Jones (not verified)

Please help me. I need to learn how to multiply on a chinese abacus. Please contact me ASAP (As Soon As Possible) !!!!!!!!!! Thank you for your time.

- Nikki S. Jones

by Dee (not verified)

Funny that: Alas this is many months late: (I hope this helps someone else if not you).

The first teaches how to use Chinese abacus. The second teaches multiple versions of the abacus (from a cursory glance at the site). The third I chose as an additional resource. (These are the best three of what I have found)

1)Complete site on the Abacus - How to use, build, history, etc. (2/5 bead)
(Good Resource)
http://www.ee.ryerson.ca:8080/~elf/abacus/

2) Math Mojo with an Abacus (Good Resource)
http://www.mathmojo.com/index.html3)

3)Think Quest on line: Abacus
http://www.thinkquest.org/library/lib/site_sum_outside.html?tname=C00584...

by Navindra Umanee (not verified)

Art wrote me with more exciting details on the upcoming version(s) of Citadel. Quoted here with author's permission.

Art J. Cancro writes:

Hi. I saw your review of the Infusion client and the Citadel/UX server,
and was quite happy to read it ... because I happen to be the lead
developer for Citadel/UX. :)

One thing I thought you might like to know -- the version of Citadel/UX
which is about to be released has working IMAP support. So you'll be
able to point your "mutt" client at it using IMAP, and it'll work. Private and public folders, it's all there!
Incidentally, Citadel also has a web-based front end called WebCit.
It's very nice, and once Brian is finished with the calendaring stuff
in Infusion, I intend to add web support for that as well.

Then comes the really ambitious undertaking: we're planning to write a
MAPI driver for Citadel. This will make Citadel the first open source
groupware server to fully support the calendaring/scheduling features in
Microsoft Outlook to the same degree that Exchange does. This is
significant because on a Citadel network, non-Outlook users don't have
to be second class citizens. You'll have full access to the calendar
functions (and everything else) regardless of whether you're using
Outlook, Infusion, or a web browser.

Just thought you'd like to hear more about what's going on with what I
believe is an important project that has lots of potential.
Incidentally, I am composing this e-mail to you using the SMTP/IMAP
client in Netscape 6.1PR1, connected to my Citadel server.

by Jason (not verified)

If you truly want to compete with Outlok and Outlook Express, Secure Password Authentication needs to be added. This is so vital to some of us, I can't understand why noone has done it yet.

by anon (not verified)

Evolution has already done it...

Let me mention another similar solution in the same problem/solution-space, Bynari's Insight [formerly TradeServer/TradeClient] at http://www.bynari.net

However, if you look at SourceForge, the most popular mailserver seems to be CourierMail [ # 18 most popular download this week ]. Probably because it offers a web interface as an option. Things like global address books and calendaring are important, but without a web interface, it is only half-way there. There seems to be two threads here: 1. The 'Enterprise' Exchange type server that give the typical office worker a calendar and 'global' address book on their local server and maybe IMAP (ie stays on the server, not downloaded). 2. Internet mail, either through a mail client or the browser.

A killer app will be the one that combines the two...

"There seems to be two threads here: 1. The 'Enterprise' Exchange type server that give the typical office worker a calendar and 'global' address book on their local server and maybe IMAP (ie stays on the server, not downloaded). 2. Internet mail, either through a mail client or the browser."

Actually, Microsoft Exchange does both of those. There is an Outlook Web Access component that gives you client that lacks many of the additional features of the full Outlook client, but is still reasonably usable, even on non-Microsoft platforms (although Konqueror has problems with the javascript on OWA for Exchange 5.5). I think any program that wants to get well used will need to implement both, because accessing e-mail through a webbrowser when you're local seems rather inefficient, and using a mail client to read your mail when you're remote seems insecure and usually too slow. Web-based mail systems seem to work the best when you're remote and just need to quickly check in, whereas local clients seem to work best when you're hardwired into the LAN, where you'd like nearly instant notification when someone mails you.

Without both these features, it'll be hard to compare to conventional proprietary systems like Lotus Notes, Microsoft Exchange and Novell Groupwise.

Besides 'complete solutions' (i think citadel/UX is such one, but i may be wrong), i would like to have 'modular solutions'. Look at the existing unix system for mail: we have an incoming mailserver like sendmail/postfix/qmail/exim, we have unix accounts, we have procmail, we have things like pop3d/imapd ...
I'd like a similar solution for all the other features we need in a pim solution, and maybe even we could reuse existing components (we don't need a new mta ...)