From: Joachim Werner (joe_at_suse.de)
Date: Wed Jun 02 2004 - 16:39:15 CEST
Message-ID: <40BDE693.5020900@suse.de> Date: Wed, 02 Jun 2004 16:39:15 +0200 From: Joachim Werner <joe@suse.de> Subject: Re: [taskjuggler-devel] karm integration?
Hi!
>>So what you need is a way to
>>convert the entered data from the calendar into taskjuggler and
>>translate it in a form that is usable for taskjuggler (TJ specfile).
> I think the way to do this is write a new libkcal resource that
> reads/writes calendar data to a TJ specfile. Then KOrganizer could just
> open the file, just like it can open webdav, ftp, OpenGroupware, Yahoo
> Calendar, etc, etc.
That's what we are planning for KOrganizer. Excuse my ignorance: Is karm
using the same libkcal resources?
The idea for KOrganizer is to make it read the TJ XML and write back TJ
files with supplements to the tasks (I'd prefer using XML there, too,
but the TJ specfile format would do the same). These TJ files can then
be included in the master files that generate the schedules.
We just want to write back completion info in the first take. karm would
probably use a more fine-grained approach (writing back bookings).
> Are the booking lists stored in the specfile? Based on the sample format
> Chris showed me, I would guess the answer is no.
Well, TJ uses the same format for reading and writing. The files that
are usually used to specify a project are not using bookings in most
cases. But TJ can write files that contain the scheduled bookings. You
can reimport those into TJ, e.g. if you want to base the results of a
master plan on the exports written by sub-plans.
>>Next as the results of taskjuggler are stored in a html file or an XML
>>file, the results could be shown to the user (html) or fed back to
>>KOrganizer (XML?). However, there are going to be many issues on
>>resolving conflicts.
That's why our idea was to start with completion info because this
doesn't break the schedules. It just adds information about the
completion status.
> My idea was that the karm data would let you produce a chart where you can
> visually compare actuals versus scheduled.
That's possible I think. At least if you are using scenarios.
>>In my opinion, the _only_ sensible way to integrate KOrganizer with
>>taskjuggler is with a project view plugin. In that case all tasks in the
>>_project_ can be scheduled by taskjuggler. But to make it really worth
>>while, you would need to update the tasks in KOrganizer with the results
>>from TJ. This is exactly what I have done in my application using PyTJ
>>(but not KOrganizer). PyTJ could be used as a basis, but should be
>>adapted to define XML for input. Furthermore PyKDE could be used to
>>define the necessary communication.
>>To accomplish this, the plugin should be able to write an XML spec-file
>>based on the projectdata in KOrganizer. Then it should be able to run TJ
>>and after that, it should be able to feed back the results from XML to
>>KOrganizer.
I think that for most scenarios the "round trip" is not necessary. It
should be fine if KOrganizer gets a current XML file (e.g. one that is
updated daily) and writes back a file that contains all completion data
that accumulates during the day. This data is then used in a nightly TJ
run to update the XML files KOrganizer reads. Conflicts can only occur
if two users work on the same task (which is a problem software can
hardly solve).
If you want to give the "end users" more influence (e.g. change the task
priorities) things are more complicated of course. In that case a
centralized approach is certainly easier.
>>- Some data is not present in KOrganizer, especially the more advanced
>>options that can be used by taskjuggler. This shouldn't be a problem to
>>start with, but in the future, there should be a way to enter this data,
>>because in the real world for a planning to be useful, the more
>>complicated functions will be used a lot. (I know as a former project
>>manager....)
Right now we are thinking of two ways:
- For the end users (the ones who get the scheduled tasks from the
system and report back what they've done) we are planning to use
KOrganizer (or similar).
- For the project managers we think of a "TJ IDE" as a first step, i.e.
still working on the TJ files, but having syntax highlighting,
auto-completion etc. to help you, and being able to test-run the
specfiles like you can debug C++ code in KDevelop.
>>- Project begin and end-dates are crucial, and should be derived from
>>the first and last task that are to be scheduled, however, it is not
>>always clear when the last task ends (that's why we are scheduling ;-),
>>so there is some pretty clever coding necessary to get this right...
>>- If a conflict arises, the tasks in the tree are not scheduled and
>>there should be a way to inform the user when this happens (perhaps an
>>errorcode in the resulting XML?) on all tasks that are affected.
>>- TJ has no optimization (yet), which means that most of the time
>>scheduling is suboptimal, and should be tweaked by juggling with
>>priorities. Off course it is no problem to start with, but in the long
>>run, there should be a kind of optimization that at least avoids obvious
>>conflicts.
Chris is working on optimizer code for TJ ...
> I have a degree in operations research, which I have never really used.
> Maybe this could turn into a reason to dust off my combinatorial
> optimization texts ... ;)
;-)
>>- What happens if a project is updated by more than one person at the
>>same time, both of them asking to schedule the tasks?
>>- Is taskjuggler always run at the desktop, or should it be run as a
>>batch process somewhere on a server? Could be very useful for bigger
>>projects.
For large projects we will need a dedicated project server. I'm
experimenting a bit with using Zope for that (because it comes with
WebDAV and XML-RPC for free and makes it easy to add a web frontend to
the story). Right now I am not using PyTJ but run Zope as a "user" who
checks out the specfiles from a CVS and manipulates the files like a
project manager would do. But a more dynamic approach would certainly be
great.
> I prefer Python, but I can talk C++. ;)
Welcome to the club ;-)
> Another piece to consider in this puzzle is kplato ... but I can't even get
> that to build right now.
Probably not worth the effort ...
-- Joachim Werner SUSE RD-TPM -- To unsubscribe, email: taskjuggler-devel-unsubscribe@suse.com For additional commands, email: taskjuggler-devel-help@suse.com
This archive was generated by hypermail 2.1.7 : Wed Jun 02 2004 - 16:39:21 CEST