From: Dick Kniep (dick_at_kniep.nl)
Date: Thu Jun 03 2004 - 00:50:39 CEST
From: Dick Kniep <dick@kniep.nl> Date: Thu, 3 Jun 2004 00:50:39 +0200 Message-Id: <200406030050.39386.dick@kniep.nl> Subject: Re: [taskjuggler-devel] karm integration?
On Wednesday 02 June 2004 18:10, Joachim Werner schreef:
> > I thought the specfile was the XML. I'm going to have to read some
> > documentation.
>
> TJ has two specfile formats, one is XML (to be precise there are two
> versions of it) and one is the more programming language-like. Both are
> basically equivalent, but the XML format has not all the features of the
> "classical" format yet.
That's also why PyTJ was created. It generates the specfile based on input
from a calling function and returns the generated XML file to be processed by
the calling function.
I think TJ should be used as a planning engine in the background. So, tasks
and resources are entered in KOrganizer, (perhaps by more than one person)
for a specific project. After a while, someone (?) pushes a "plan" button (or
a cronjob?), and the tasks are written to a TJ specfile (or XML file) and
planned by TJ, and the results (the resulting XML file) are written back to
the tasks of KOrganizer. This is not hard, as long as the tasks and resources
can be read easily from KOrganizer. Maybe there is a plugin available that
can be adapted to do just that. After the tasks have been read, they can be
written to the specfile by PyTJ, the same plugin could later be used to read
the XML file and write back the results.
However, after thinking about the multi user problem for a while, this might
be a bit optimistic, because there can be many instances of KOrganizer with
project data. This data should be merged first, and after that can be
processed. Then after processing by TJ the results must be distributed back.
I think this is undesirable, and therefor, a project should always be stored
on a central server (the controlling server).
>
> >>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.
> >
> > % done shouldn't break the schedule either, right? It just tells you how
> > many hours are really left on the task. I guess it all depends on how
> > fine-grained you make your tasks. Done/Not-done will work well if you
> > use small tasks.
I think this is beside the point. Whether you write back all information or a
small portion, the amount of work that has to be done is virtually the same.
The only real issues here are the multi user issue and the error reporting
(as mentioned earlier).
>
> Well, but that won't give you anything close to what you can do with TJ
> right now. It's like graphical programming: You can do part of it (think
> UML with code generation), but it's not quite there yet.
>
> That said, there might be ways to combine both approaches. I just
> haven't found a perfect solution yet ...
>
> > Why a dedicated server? Couldn't you could just put the TJ XML file on a
> > shared drive (or FTP, or SSH) and use remote resources in KOrganizer.
>
> To some extend yes. But if you are rescheduling you need a controlling
> server instance that makes sure that everything is kept in the right order.
Yes this is very valid, and touches on the real problem: Multi user planning
of tasks. The reason this is important, is because hours are entered by
different users, and should be processed by a controlling server instance.
(Maybe I am repeating some of the discussion, my apologies)
Cheers,
Dick Kniep
-- 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 : Thu Jun 03 2004 - 00:55:11 CEST