[Kolab-devel] RFC: Format proposal for time tracking data
wrobel at pardus.de
Thu Jul 3 07:29:27 CEST 2008
Bernhard Reiter <bernhard at intevation.de> writes:
> On Tuesday 01 July 2008 17:03, Gunnar Wrobel wrote:
>> Please take this only as a very early draft only meant for getting
>> some comments and ideas.
> thanks for publishing the draft.
> My idea is to get spec 2.0 released and then set up a better process
> for going from there. Doing draft releases or KEPs (Kolab Enhancement
> Proposals) is a good idea. I guess we should track them somewhere,
> e.g. in the Wiki.
Yes, Wiki would be good.
>> While the suggestion is only proposing a theoretical data format it
>> is of course driven by an existing client application.
>> Horde released "Hermes" (http://horde.org/hermes/) yesterday. This is
>> a small time tracking application that interfaces nicely with the
>> other Horde applications (addressbooks and tasks). I already wrote a
>> Kolab driver for this app now but I'll keep this private as long as
>> there is no common format we can agree on.
>> I hope there are some other devs that would like to use time tracking
>> on the Kolab server, too.
> Of course it would be fine to have a format for this.
> You've missed how many folders you would propose for this?
Yes, I forgot that. The current implementation uses a single IMAP
folder of type "timetrack". But now that you asked I thought about it
again and I believe it might actually make sense to store it alongside
with the associated tasks.
Horde currently allows to assign time track data to so called
"cost-objects". As far as I know these may be tasks and bugs (in the
Horde bug tracker called "whups"). So for Kolab time tracking
currently only works with tasks. Each time track object now carries a
cross-reference to the UID of the task (element "cost-object" in the
schema I proposed).
I actually don't like using a reference across IMAP folders too
much. Currently such references are still left undefined by the Kolab
format if I'm not mistaken. I believe we should tackle that problem at
some point and also clarify on how UIDs are to be used.
But for the specific task of storing time tracking data I think it
would also make sense to store it directly in the IMAP folder of the
> Also for a good completion we should look at how other clients do it,
> so that our first move is already good enough to cover a large section of the
> problem space.
Absolutely. That is the main reason why I posted this. I would like to
have at least one other candidate application that might have a chance
of implementing this in the forseeable future.
> Clients like "worklog" (which I use for timetracking) or KArm and whatever
> people use on Windows/Outlook.
I checked KArm (which has been renamed to KTimeTracker for KDE4.0) and
I believe it has the necessary potential to become another Kolab
client app for time tracking. It integrates with Korganizer and can be
used as a plugin in Kontact. That sounds good to me.
I'll have a look at this and will check what type of data it
"worklog" did not see any development over the past four years if I'm
not mistaken. And as it is also a web app I guess it would be easier
to cover that ground with Horde.
> Managing Director - Owner: www.intevation.net (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> Kolab-format mailing list
> Kolab-format at kolab.org
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
More information about the format