Update....

Thanks to Brad Hards' quick intervention, I have a tarball of a recent SVN snapshot for OpenChange. I'll build the code and start working on reviewing the API tomorrow.

Stuck....

This is a special request:

The last couple days, the OpenChange project's website has fallen off the 'Net. As one of the steps in getting my development environment up is installing libmapi++ (which no distribution seems to have packaged at all), I'm stuck. If anyone knows the folks maintaining the OpenChange project's website, please find out what is going on. Also, if anyone has a current check-out of the libmapi++ tree, please let me know so I can get it from you. Thanks.

You may now return to your regular blogging enjoyment.

Trudging Through Another Build....

After spending an evening getting my development environment updated to trunk, I think I've come to a few conclusions: 1) I need to learn more about CMake, 2) learn how to deal with missing headers better (thank you ervin) 3. don't resort to sledgehammer methodology as quickly to fix a problem, 4) work on my my patience level more.

After committing the fix from being the guinea pig for the fix, I'm onto building kdepim, and then I'll start working on getting the code fixed for the openchange resource so it compiles.

Answering Questions.

Just so those that are curious know, I'll repost my response to the over a dozen comments to my posting last night......


Just a small fyi for those that have been commenting:

Yes, my aim is for 100% parity with Outlook's capabilities with MAPI. This means that Mail, Contacts, Calendar, Notes, Journal, Public Folders, Tasks, and Projects are on my TODO list.

Whether this will use openchange for all of that functionality has yet to be decided based off of testig and feature completion.

Also, I think I should make it clear: the code I'll be working on was started in development around 2007 by Brad Hards and continued by Alan Alvares for his 2008 GSoC project. This WILL be an akonadi resource that talks Extended MAPI/RPC to the Exchange server and DBUS back to the Akonadi session daemon. Where necessary, I might call things in the various libraries from the Samba4 project to mimic an Active Directory backed Exchange client to make my work easier, we'll see if I have to do that or if I can rely on some things from LDAP..... Onwards and Upwards :)


With this, I need to stress that it won't be instant progress on this, so please all, be patient :)

Hello planetkde!

This is my first posting on the planet (I hope... the aggregator doesn't seem to be showing my feed.... Here goes crossing fingers....)

Some people in the community may know me as the guy that likes Perl, Qt, KDE, and does a hell of a lot of IT administration at a very un-KDE job. I've helped out at a few F/OSS related events around the San Francisco Bay Area, including hosting lodging for three of the people that helped at the O'Reilly OSCON event earlier this month.

A large portion of the stuff you'll read about from my feed will be related to my (mis) adventures with getting KDE integrated with Exchange 2003 and later. I'll get into that a little more in the next post.

KDE, PIM, and MAPI

Enough acronyms for you? I thought so.... For those that might not have heard, I'll be taking on the challenge of getting KDE PIM fully Exchange capable. This comes from my desire to kill Outlook and Entourage from my life and not force me to use a tool not integrated very well into my desktop of choice (Evolution).

So what is MAPI, you might ask? Well, MAPI stands for Messaging Application Programming Interface, which is the tier one option if you want a mail client to talk to Microsoft's Exchange server. This interface has gone through a number of changes over the years and thus far has been an elusive target for F/OSS projects. Lately a project called Openchange has been working on a library that much of my work on kdepim will be focused around integrating into KDE. This library covers all of the mess of having to write our own library to get access to these servers. As some know, this library is already used in a native MAPI method in Evolution that was released recently in the routine releases of GNOME. I'll just leverage that work and make KDE just as accessible to Enterprise users stuck in an MS powered shop.

I'll try to cover all the things I do to make this a reality, so stay tuned, Fun stuff ahead :)

APP-Get Progress

I've gotten the code for the SourceManager mostly done, need a dumper function at this point and then I can utilise it in app-update. After that LWP code will be high on my list as I add the DownloadManager functions.

Code tally....

While this normally falls under the "pissing match" category, I thought this would be fun to show how much code can be shaved off of a project that is written in pure Perl versus C++ and a Shell wrapper. The old genbasedir from Apt-RPM clocks in at 1650 lines of code, not counting the includes in the C++ source files. The NEW genbasedir.pl from APP-Get clocks in at 473 lines of code. A whopping 2/3 code reduction alone. Mind you, I could have cut corners, and trimmed the code down even further, however after looking over the code that genbasedir from Apt-RPM have between the shell script and the two C++ files, there are more than a few areas that look dodgy and lack proper error checking. Tomorrow, I'll move most of the functions from genbasedir.pl to a module to make it unit testable. Stay tuned to further developments :D

Reworking genbasedir....

To make genbasedir easier to work on in the future (when we move to using some SQL engine for the data store for metadata), I reworked the functions to allow us to use an integer based pkgId instead of using the string name. This should speed up the dependency map functions in app-get considerably when doing package look ups since string comparisons aren't the fastest operations in the world in any language.

As an aside, I've gotten buy in from Jeff Johnson, the maintainer of the version of RPM at www.rpm5.org to add in some Debian inspired tags to make my work on app-get easier. :)

New APP in town :D

Just an update, I'm working on a new dep solver for RPM and the eventual general successor OPM. The utility is called APP-get, a clone of apt-get that doesn't rely on private API in the underlying package manager to work and crufty code that Apt-RPM does. To get a feel of how APP-get will retrieve the metadata, I've been reimplementing genbasedir.

At this time, I've much of the new genbasedir written. It writes out a new plain text database format for binary and source package metadata called a lst.db. Each file is a single table of fields delimited by three pipe characters in a row. With this new set of lst.db files, a person can generate the metadata using standard UNIX tools if they so wish (though I don't know why you'd want to, since genbasedir does such a nice job of it :D).

While writing this, I've been studying the dependency map algorithms used by Apt and SmartPM. Armed with the knowledge of how they determine the dependencies, I should have a fairly easy time of writing the dependency manager in APP-get.

As I've been writing the code, I'm noting a lot of places that I'll be able to clear out Debian-isms from the design, which makes the codebase and design far simpler. At the same time, I'm seeing features I'd like integrated into RPM5 to make some aspects simpler, such as package priorities.

In Apt-RPM priorities are implemented as a kludgy list file (rpmpriorities) in /etc/apt/ that is checked for a string representing the name of a given package that uses a YAML-like format that defines packages according to named priorities which are more like the Essential tag in dpkg. I'd like to change this to be INSIDE the package's header to allow distributions to mark certain packages that don't normally have a require against another as Priority: Essential, or Priority: Normal. Also if this was merged into the header of the package, it would allow rpm to gain the ability to stop people from shooting themselves in the foot with rpm -e or app-get remove.

Well, enough chatter for now. Look forward to more progress on APP-get.