[rt-devel] You should really get the HTML out the code....

[Rich West]

Okok.. enough with ACID.  If we really wanted ACID, there wouldn't be MySQL
support out there.  :)

That, and, honestly, if the direction of development turned towards Java, I can
honestly say that a fair amount of people (myself included) would not follow.


Handling the issue of having multiple people have access to the same contents,
and potentially have actions overlap, is entirely an implementation issue.
Sure, you have policy here and preventitive code there, but it really boils
down to the basic priority: You want to have the end customer's issue
addressed.

If you have situations where a ticket is locked while another admin is working
on it, you introduce the new problem of having to deal with situations were the
ticket needs to be forcefully unlocked: Admin left for the day, but left the
ticket in a "view" state, app crashed (can we smell the Java in this one?) and
left the ticket in a locked state, etc.

HTML/CGI is fantastic for limiting the impact on the administrative clients (it
doesn't take a hefty CPU to use RT) as well as the server (Apache + RT =
lightweight).

The problems that were immediately pointed out are all in the back-end.. in
most setups, the end customer does not see them, and there are better ways of
dealing with the issues than falling for the "Java can do everything" line..

A Java implementation _might_ work well in an environment where everything is
on a nice fast LAN, all of the administrative clients & customer machines (if
they connect into RT) are of the same platform, everything is beefy, and you
don't want to customize it.  Java is still so touchy that it scares the crap
out of most people.. who wants their browser to hang?

Another thing to remember is that RT is a bit more than a "ticketing system".
It's a helpdesk system..

-Rich

PS: The whole "java" push is one that just drives me nuts.  Java has yet to
live up to what has been promised.  It's far from lightweight (take 4 lines of
java, and you've got to load the entire interperter/compiler on the client,
within the browser, and pray to whomever that the browser doesn't crap out on
you).

PPS: Way back at an old company I was working at, we developed an in-house
java-based helpdesk system which would do the ticket locking and hierachial
(sp?) views of the tickets, and more.  It took us (4 SA's) over a year to
write, with the help of some of the company developers.  The end result was
something extremely customized to our environment and, although it worked well,
it wasn't fun running it from home over a 128k ISDN line.  The benefits of Java
certainly don't outwiegh the expense of the implementation (client side
limitations, poor JITs, and fragile code, etc.)


> What I am suggesting is basic database ACID compliance. Admittedly, it is
> not very easy to achieve in a 3 tier web environment where connections are
> stateless, BUT never-the-less I think your application MUST incorporate it
> to be taken seriously. Checking a row's timestamp, and updating it
> appropriately as each web page is fetched/updated is a common way to take a
> "step towards" ACID ....
>
> It is very important to achieve ACID in an application such as yours,
> because you will have a "queue' that can potentially be accessed at the same
> time by multiple people - you must co-ordinate access to updates of the
> queue.
>
> Also I think you are not handling "multiple duplicate" requests, where the
> user quickly clicks form same button multiple times -you should not execute
> the action on the server multiple times....
>
> I might suggest abandoning CGI and go with JSP and the J2EE platform..... I
> think much of this could be taken care of in the J2EE environment (JSP HTML
> templates, applications sessions, EJB transactions).... CGI is old news.....
> "Go Java, Young Man"...
>
> just my two cents.... However, I do appreciate the work you have put into
> your application....it shows a great deal of effort.... I certainly have not
> found another open source project that does what you do -and I really need
> to look at your version 2....BUT actually there is a SUN J2EE specification
> for an API that is being worked on for "ticket systems".... this would
> standardize and open source "ticket tracking" api for flexible
> configuration.....