Summary of "TTS Request for comments" response

Hallo all,

in the past week there came several comments in reply to my request,
thank you for them all. They addressed several issues and in this email
I'll try to summarize them and reply to them.

1. Suggestions intimately related to the project
It was suggested to use the UML for visualization instead of Petri Nets.
As far as I understand, UML is just a language for describing models,
and Petri nets can be described usig UML. Certainly the suggestion is
interesting and will be addressed later, when visualization of Petri nets
will be implemented.
Another comment was to use TTS for various systems, not just bugs
(such as computer and network problems, down to lihgt bulbs and up to
inventory sales). Indeed, this is exactly the point. Using the suggested
upgrade it could be done by having several entry points into the Petri net,
and later this will be done having several different Petri nets in the system.

2. TTS, Bugzilla, anthill and other systems
We have been using anthill for a while and this also initiated the whole
thing. The initial idea was to port AH into PHPGW, and later I realized
that Dave has started on it. I've obtained his code from the CVS and
started to work on it, fixed some things and managed to finish the form
for displaying bugs. But then the TTS appeared again, and as in Anthill
there was lots of coding that was just the hardcoding of specific Petri
Net into PHP I decided to cut it there and solve things in a more general
way using TTS. As I propose, the default Petri Net in TTS will be the one
for Anthill, therefore it could be considered as a replacement.

However, the users should be aware that the generalisation has its costs
and also that the datamodel of TTS a subset of the datamodel of Anthill.

If there is any interest in continuing the work on Anthill, contact me to
send you the code I wrote, as I will abandon that and work on the TTS.

There were suggestions for using RT's API and some other systems were
also mentioned: I am sorry to say but these things are beyond the scope
of the project. Thank you for the hint, however: if we find an use for
that, then we'll try also to find time to implement those ideas.

3. Platform issues and paralel developement of the TTS

I intend to post the finished project on both PHPGW and EGW CVS
repositories, if a team of some project has a problem with that, please
let me know. I was also told that there is some parelel developement
of TTS going on simultaneously: this makes me believe that the choice
of TTS was the right one. In the past days I have developed the main part:
the implementation of Petri Net in the TTS, and it required adding a new
field to the ticket and modifying the new_ticket and view_ticket forms and
the index as well. The rest of the project that I still intend to do deals 
with
maintenace of the Petri Net itself and is independent from the rest of the job.

I suggest two ways of merging the changes: first would be that one finishes
the upgrades and submits the new code to the CVS (together with all upgrading
infrastructure) and then the other submits his code as an upgrade of the new
code. I volunteer to be the second one, as inserting my code into any other's
does not require much work.

The second would be that we exchange the files and upgrading instructions and
then produce a single new version of TTS. This would probably require a bit 
less
coding effort, but more organization and interdependencies. However, it would
connect us closer together (and eventually, we can even meet for a glass of
beer :)

4. Connecting TTS with other XGW applications
Since using the GW I have observed that the applications and their data are 
in general
poorly interconnected. Therefore we proposed a system called Pajek, that would
implement the general relation infrastructure into the GW. The idea is that 
various GW
applications produce sets of objects, one just has to define RELATIONS on 
those
sets of objects. The system could be both integrated into the applications, or
independent from them, so that apps themselves do not know about it.
The prototype of this system will be ready by the end of october as well.

Unfortunately the specifications of the system Pajek are currently only 
available
in Slovenian: http://lp.fmf.uni-lj.si/~drago/Pajek_spec_00.pdf
The english translation will be ready at least with the prototype of the 
system.
Such system probably requires more integration with the API and therefore more
work from the side of the dedicated GW develoeprs, therefore we wanted to have
first a working prototype (and therefore a proof of the concept), and only 
then start
communicating with the GW's community.

5. Extra features:
There was a list of features suggested, which unfortunately reach beyond the
scope of this project. Let me summarize them here, if someone finds motivation
to implement them:
* advanced handling of the user notifications
* advanced ticket filtering
* more sophisticated use of categories to categorize tickets

I've integrated the comments into the new version of specifications,
which is available on http://lp.fmf.uni-lj.si/~drago/tts-petri-ug.pdf

Again, thank you all for your contributions, time and ideas suggested.
If some new ones appear, they will be appreciated.

Drago Bokal