From: Mark Bucciarelli (mark_at_easymailings.com)
Date: Wed Jun 02 2004 - 16:07:20 CEST
From: Mark Bucciarelli <mark@easymailings.com> Date: Wed, 2 Jun 2004 10:07:20 -0400 Message-Id: <200406021007.20384.mark@easymailings.com> Subject: Re: [taskjuggler-devel] karm integration?
On Wednesday 02 June 2004 09:28, Dick Kniep wrote:
> On Wednesday 02 June 2004 11:31, Chris Schlaeger schreef:
> > Hi Mark,
> >
> > sounds interesting. Lukáš is indeed working on an improved version of
> > our viewer. This might even become more than a viewer later.
> >
> > TaskJuggler is more a compiler than a database. So adding a DCOP
> > interface does not make much sense. But a potential coupling of Karm
> > and TJ could be the import of task list into Karm and the export of
> > booking list into TJ projects. TaskJuggler is currently only a stand
> > alone tool that can be (and already is) used by project management
> > frameworks. But these frameworks are only in-house solutions tailored
> > to the needs of the companies using it. We don't have a generic
> > solution yet.
>
> Chris is completely right. a DCOP interface is ment to access online
> data. However, taskjuggler is a real _batch_ application, that plans
> activities (and does a great job at that).
Yes, of course. TJ is a processing engine. My mistake.
> 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.
Are the booking lists stored in the specfile? Based on the sample format
Chris showed me, I would guess the answer is no.
> 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.
This I need to think about.
> The example you mention (Karm) is meant to store hours as they are used
> by users, and those hours can be billed. That is a different ballgame,
> as far as I understand there is no planning involved here.
My idea was that the karm data would let you produce a chart where you can
visually compare actuals versus scheduled.
> 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. However there are some considerations on resolving
> conflicts:
>
> - 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....)
> - 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.
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.
>
> OK, enough for now. If you really want to start this, and I do not have
> to many customers that are paying much money for my services ;-), I
> could help you. However, I talk python, no C++.
I prefer Python, but I can talk C++. ;)
Yes, I agree, enough for now. :) I have quite a few things on my TODO
list that come first.
But this discussion was very helpful--it gives me a better overall picture.
Maybe later this summer I can start hacking a bit.
Another piece to consider in this puzzle is kplato ... but I can't even get
that to build right now.
Regards,
Mark
-- 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:07:35 CEST