Interfacing with RT via PHP

RT Users
1

Hi all,

Are there anything available that’s written already to interface with RT’s
tickets via PHP?

I’d like to have a type of system where I can inject a html form as a ticket
into various RT queues. For example, I may have a support form on a html
page, where the user provides his / her email address, and a detailed
description of the problem.

I’d like to then take the form data, inject it into RT, and provide the user
with the ticket number over the web.

Is this at all possible? Anything written for it already?

Kind Regards,

Chris Knipe
MegaLAN Corporate Networking Services
Tel: +27 21 854 7064
Cell: +27 72 434 7582

2

What are your motivations for using PHP rather than HTML::Mason?

A while back, since I wasn’t comfortable with the state of RT’s
unauthorized user interfaces, I created a PHP interface to simply email
a ticket in and then I linked to a NoAuth list of tickets in that
queue. I ditched it before we moved RT to production, though, in favor
of HTML::Mason stuff that is much better because it sits on top of the
RT API.

I’ll gladly provide the stuff I’ve done with HTML::Mason, but I’m
afraid there’s not much I can help you with as far as PHP interfaces.

Matt

Chris Knipe writes:

3

Are there anything available that’s written already to interface with
RT’s tickets via PHP?

One thing I’m interested in doing, if only I had the time, is an XML-RPC
interface to RT (XML-RT ?). Once that is in place, you could interface
with RT from any client or programming language. Every popular language
that I can think of has XML-RPC bindings (including PHP, of course), so
there would be no need to limit WebRT to being implemented using
HTML::Mason; the current WebRT could be rewritten to use XML::RPC as the
underlying API, rather than the Perl modules.

The best part of this would be that Jesse would be free to concentrate
on improving the base of RT. After all, the main reasons to use RT are
the complex database it contains; the well-defined, yet still
extensible, relationships between tickets, users, and queues; the Scrips
and other automatic actions for which RT allows; and so on. The various
interfaces are secondary to the data that the libraries provide access
to. In fact, all the current interfaces, plus some new ones, would
probably be easier to write and maintain if they were presentation-level
wrappers around XML-RPC calls.

This is a long way off, of course. But it would be practially ideal.

To answer your question, however, the easiest thing to do would be to
have the PHP script fire off an email to the email gateway, and ensure
that there is an OnCreate scrip to respond to the user.

(darren)

Usenet is like a herd of performing elephants with diarrhea;
massive, difficult to redirect, awe-inspiring, entertaining, and a
source of mind-boggling amounts of excrement when you least expect
it.
– Eugene Spafford.

4

I built a really crummy ad-hoc XML interface to RT, based on the Perl RT
API, and it works OK. I’d be a little embarassed to release it to the
world with any sort of presumption that it’s complete, correct, or even
close to following standards that it should follow. But, I would consider
posting it to the list for folks to gawk at and (even better) spend some
time making it buzzword-compliant.

Let me know if there is interest…

Dave

David C. Troy [dave@toad.net] 410-544-6193 Sales
ToadNet - Want to go fast? 410-544-1329 FAX
570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.netOn Mon, 17 Jun 2002, darren chamberlain wrote:

Are there anything available that’s written already to interface with
RT’s tickets via PHP?

One thing I’m interested in doing, if only I had the time, is an XML-RPC
interface to RT (XML-RT ?). Once that is in place, you could interface
with RT from any client or programming language. Every popular language
that I can think of has XML-RPC bindings (including PHP, of course), so
there would be no need to limit WebRT to being implemented using
HTML::Mason; the current WebRT could be rewritten to use XML::RPC as the
underlying API, rather than the Perl modules.

The best part of this would be that Jesse would be free to concentrate
on improving the base of RT. After all, the main reasons to use RT are
the complex database it contains; the well-defined, yet still
extensible, relationships between tickets, users, and queues; the Scrips
and other automatic actions for which RT allows; and so on. The various
interfaces are secondary to the data that the libraries provide access
to. In fact, all the current interfaces, plus some new ones, would
probably be easier to write and maintain if they were presentation-level
wrappers around XML-RPC calls.

This is a long way off, of course. But it would be practially ideal.

To answer your question, however, the easiest thing to do would be to
have the PHP script fire off an email to the email gateway, and ensure
that there is an OnCreate scrip to respond to the user.

(darren)

–
Usenet is like a herd of performing elephants with diarrhea;
massive, difficult to redirect, awe-inspiring, entertaining, and a
source of mind-boggling amounts of excrement when you least expect
it.
– Eugene Spafford.

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

5

Lo there,

  1. It’s a PHP based application. I’m not going to rewrite over 3 million
    lines of code on a web application to allow me to insert data into a
    database via mod_perl. That just morally isn’t right, and doesn’t make any
    sense to me what so ever. Needless to say, it will be over a year’s worth
    of work that I need to re-do…
  2. Databases are universal, and they are accessible through various
    programming languages and APIs, which also motivates point 1 a bit more I
    think.
  3. I’d like to steer away from mod_perl on a production level (this is a
    personal opinion, and I have my right to express them). While on non
    critical systems, I’m more than willing to use it. From past experiences
    I’ve had with RT and mod_perl, I don’t like the idea of having those high
    system loads when a RT web sites becomes very busy. On our development
    system, while receiving ± 30 emails per minute, our system’s 15 minute load
    average went up over 5.4. I’ve also noticed this with load scenario with
    other mod_perl based applications I wanted to run, all of them resulted in
    the same, which tells me its a mod_perl issue, and not RT, so flames and
    wars here will kindly go to /dev/null. The fact of the matter, is that I
    don’t like mod_perl, and there is no way that I am putting this on a
    production system.
  4. mod_perl is also Unix specific, which may become a problem. With a
    universal way of accessing the data, I can even integrate ASP (Win32) based
    sites, as well as C++ / Delphi programs to interface with RT. This will
    also become a big problem at a later date, seeing that our company’s
    internal management systems will be in Delphi / C++, and not web based. So
    either way, this is going to become a problem for me over the next few
    months, seeing that PHP and Perl is not the only languages I need to give
    access to RT’s data.
  5. I can’t simply email the ticket, because the ticket will be send back to
    the sender of the ticket itself.
    5.1) If this is sent to the user who submitted the form, I can’t reference
    the ticket number on the site
    5.2) If it’s sent back to the web server’s user, there may be long delays
    until I am able to pop the mail from a mailbox to retrieve the ticket
    number, which can cause timeouts on the site (mail may be delayed in SMTP
    queues for example). Neither of which, is a decent way of implementing
    this.
  6. Perl apps via CGI, I don’t want to use either… If I change the layout
    or something of my site, I merely change one global function. A CGI in this
    case, would need to be recoded completely, which limits me in regards to the
    functionality of the web applications I want to use…

Shall I go on ? Let me just go eat some dinner first… :slight_smile:

If there’s a simple DB API available somewhere, or, if someone can simply
provide some MySQL database logs of where RT data is inserted and retrieved
from the database, the query is in there. All you need to insert a ticket
and get a ticket number to my understanding, is two simple database
queries… Or… Am I mistaken?

Kind Regards,

Chris Knipe
MegaLAN Corporate Networking Services
Tel: +27 21 854 7064
Cell: +27 72 434 7582From: “Matt Disney” matthew.disney@fedex.com
To: rt-users@lists.fsck.com
Sent: Monday, June 17, 2002 7:27 PM
Subject: Re: [rt-users] Interfacing with RT via PHP

What are your motivations for using PHP rather than HTML::Mason?

A while back, since I wasn’t comfortable with the state of RT’s
unauthorized user interfaces, I created a PHP interface to simply email
a ticket in and then I linked to a NoAuth list of tickets in that
queue. I ditched it before we moved RT to production, though, in favor
of HTML::Mason stuff that is much better because it sits on top of the
RT API.

I’ll gladly provide the stuff I’ve done with HTML::Mason, but I’m
afraid there’s not much I can help you with as far as PHP interfaces.

Matt

Chris Knipe writes:

Hi all,

Are there anything available that’s written already to interface with
RT’s
tickets via PHP?

I’d like to have a type of system where I can inject a html form as a
ticket
into various RT queues. For example, I may have a support form on a html
page, where the user provides his / her email address, and a detailed
description of the problem.

I’d like to then take the form data, inject it into RT, and provide the
user
with the ticket number over the web.

Is this at all possible? Anything written for it already?

Kind Regards,

Chris Knipe
MegaLAN Corporate Networking Services
Tel: +27 21 854 7064
Cell: +27 72 434 7582

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

6

AFAIK, Chris, you’re more or less out of luck. It’s not that somebody
else hasn’t done this already (I don’t know, maybe they have), but I
think a lot of people give up on PHP after they get more insight to
HTML::Mason and the design of RT.

Also, I’ve replied some more throughout the text of your message:

Chris Knipe writes:

  1. It’s a PHP based application. I’m not going to rewrite over 3 million
    lines of code on a web application to allow me to insert data into a
    database via mod_perl. That just morally isn’t right, and doesn’t make any
    sense to me what so ever. Needless to say, it will be over a year’s worth
    of work that I need to re-do…

That’s a very good justification. However, you could still reference
an HTML page, couldn’t you? Rewriting a year’s worth of work sounds
bad, but I don’t know why you’d need to rewrite it all, couldn’t you
just link over to the HTML::Mason page?

But it appears you have other concerns listed below. And, of course,
you add complexity to the maintenance of your webserver by installing
RT and all its dependencies on there.

  1. Databases are universal, and they are accessible through various
    programming languages and APIs, which also motivates point 1 a bit more I
    think.

Yeah, but RT’s API solves a lot of problems with accessing the database
directly. For example, good luck trying to query the database to find
out which ticket id you just inserted. Using RT’s modules, when you
create the ticket, you have a return value that tells you that info.
I’m not sure there’s a pretty way of doing it, but I’m not an expert,
either.

  1. I’d like to steer away from mod_perl on a production level (this is a
    personal opinion, and I have my right to express them). While on non
    critical systems, I’m more than willing to use it. From past experiences
    I’ve had with RT and mod_perl, I don’t like the idea of having those high
    system loads when a RT web sites becomes very busy. On our development
    system, while receiving ± 30 emails per minute, our system’s 15 minute load
    average went up over 5.4. I’ve also noticed this with load scenario with
    other mod_perl based applications I wanted to run, all of them resulted in
    the same, which tells me its a mod_perl issue, and not RT, so flames and
    wars here will kindly go to /dev/null. The fact of the matter, is that I
    don’t like mod_perl, and there is no way that I am putting this on a
    production system.

I don’t know that anyone on this list will flame you for expressing
frustrations with mod_perl. :slight_smile: That’s understandable. Mod_perl is
stinky, IMHO as well. I like fastcgi a lot better. It improved
performance at my site significantly, though I’m still not using
fastcgi in production because the rt mason handler for fastcgi doesn’t
do what I’d like it to do with cookies (and what the mod_perl mason
handler currently does, methinks).

You should consider giving fastcgi a try.

  1. mod_perl is also Unix specific, which may become a problem. With a
    universal way of accessing the data, I can even integrate ASP (Win32) based
    sites, as well as C++ / Delphi programs to interface with RT. This will
    also become a big problem at a later date, seeing that our company’s
    internal management systems will be in Delphi / C++, and not web based. So
    either way, this is going to become a problem for me over the next few
    months, seeing that PHP and Perl is not the only languages I need to give
    access to RT’s data.

Don’t know whether fastcgi is UNIX specific or not. I’m guessing it is.

  1. I can’t simply email the ticket, because the ticket will be send back to
    the sender of the ticket itself.
    5.1) If this is sent to the user who submitted the form, I can’t reference
    the ticket number on the site
    5.2) If it’s sent back to the web server’s user, there may be long delays
    until I am able to pop the mail from a mailbox to retrieve the ticket
    number, which can cause timeouts on the site (mail may be delayed in SMTP
    queues for example). Neither of which, is a decent way of implementing
    this.

Yeah, emailing the ticket from the web is crappy, IMHO. I agree.

  1. Perl apps via CGI, I don’t want to use either… If I change the layout
    or something of my site, I merely change one global function. A CGI in this
    case, would need to be recoded completely, which limits me in regards to the
    functionality of the web applications I want to use…

Not sure what you mean here. I guess you’re doing some kind of
site-wide include stuff for your pages. But it doesn’t really matter
whether or not I understand, I think, since your other justifications
for using PHP are pretty substantial anyway.

If there’s a simple DB API available somewhere, or, if someone can simply
provide some MySQL database logs of where RT data is inserted and retrieved
from the database, the query is in there. All you need to insert a ticket
and get a ticket number to my understanding, is two simple database
queries… Or… Am I mistaken?

You may want to look in $RTPREFIX/lib/RT/ for some of the code (if you
haven’t already), but I spent about five minutes looking for it and
couldn’t find the database insert stuff in there. And there are more
clueful individuals about than myself.

Anyway, I’d still encourage you to look at using fastcgi as opposed to
mod_perl because fastcgi’s performed much better for me. But, if PHP’s
a better fit for you, best of luck with it.

Matt

Kind Regards,

Chris Knipe
MegaLAN Corporate Networking Services
Tel: +27 21 854 7064
Cell: +27 72 434 7582

----- Original Message -----
From: “Matt Disney” matthew.disney@fedex.com
To: rt-users@lists.fsck.com
Sent: Monday, June 17, 2002 7:27 PM
Subject: Re: [rt-users] Interfacing with RT via PHP

What are your motivations for using PHP rather than HTML::Mason?

A while back, since I wasn’t comfortable with the state of RT’s
unauthorized user interfaces, I created a PHP interface to simply email
a ticket in and then I linked to a NoAuth list of tickets in that
queue. I ditched it before we moved RT to production, though, in favor
of HTML::Mason stuff that is much better because it sits on top of the
RT API.

I’ll gladly provide the stuff I’ve done with HTML::Mason, but I’m
afraid there’s not much I can help you with as far as PHP interfaces.

Matt

Chris Knipe writes:

Hi all,

Are there anything available that’s written already to interface with
RT’s
tickets via PHP?

I’d like to have a type of system where I can inject a html form as a
ticket
into various RT queues. For example, I may have a support form on a html
page, where the user provides his / her email address, and a detailed
description of the problem.

I’d like to then take the form data, inject it into RT, and provide the
user
with the ticket number over the web.

Is this at all possible? Anything written for it already?

Kind Regards,

Chris Knipe
MegaLAN Corporate Networking Services
Tel: +27 21 854 7064
Cell: +27 72 434 7582

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list

7

Matt Disney:

You may want to look in $RTPREFIX/lib/RT/ for some of the code (if you
haven’t already), but I spent about five minutes looking for it and
couldn’t find the database insert stuff in there. And there are more
clueful individuals about than myself.

That’s because it’s in DBIx::SearchBuilder rather than in the RT stuff
itself.

Also, can I just say: referential integrity. Grubbing around in the database
is just fine, so long as you’re sure you’re going to implement it in a way
that’s not going to break things.

On a general note, it seems to me that expecting to simply be able to build an
RT-based application while switching from Perl to PHP is quite like expecting
to simply be able to build a house while switching from bricks to foam rubber.

But still, people want to do crazy things, which is why SOAP was invented.
A SOAP interface to RT is being worked on; I’m sure the original poster will
be in touch with Jesse to volunteer to help its development.

Testing can show the presense of bugs, but not their absence.
– Dijkstra

8
  1. It’s a PHP based application. I’m not going to rewrite over 3 million

That’s a very good justification. However, you could still reference
an HTML page, couldn’t you? Rewriting a year’s worth of work sounds
bad, but I don’t know why you’d need to rewrite it all, couldn’t you
just link over to the HTML::Mason page?

Yes, I could. But HTML is static, the moment I make a change which would
affect the web site on a global manner, I’m faced with the odd single html
file to change here, or the odd cgi file to change there. At the end of the
day, all of this adds up and I’ll be back at sitting with 10ths of houndreds
of files that I need to change manually to reflect the changes in the file.

A good EXAMPLE (I don’t do this, it’s silly), is for example when you change
the background of your web site on every single page that is part of your
web server, via the use of a global PHP function. It’s very in depeth with
PHP, but I may have a global_prepend file, which is pre pended to every
single PHP file on my web server, which defines various “global” functions
used throughout my web site (this is what I am doing).

The global functions has various functions used throughout the site, writing
the templates for the pages. The moment I feel like changing a template, or
inserting a new image to a template, or even using changing data (like
weather information for example), I merely change it in one place, in the
global function.

So at the end of the day, I write a complete web page, in less than 10
lines…

<? WritePageStart("page title", "page description", "keywords"); ?>

my content for the page

<? WritePageEnd(); ?>

As you can well imagine, this saves me a TREMENIOUS ammount of time. Even
more than simply copying and pasting, because when and if I should ever
change something, I change it in one single location - no where else.

  1. I’d like to steer away from mod_perl on a production level (this is a
    personal opinion, and I have my right to express them). While on non

I don’t know that anyone on this list will flame you for expressing
frustrations with mod_perl. :slight_smile: That’s understandable. Mod_perl is
stinky, IMHO as well. I like fastcgi a lot better. It improved
performance at my site significantly, though I’m still not using
fastcgi in production because the rt mason handler for fastcgi doesn’t
do what I’d like it to do with cookies (and what the mod_perl mason
handler currently does, methinks).

And you don’t really come up here to defend mod_perl either. Which just
prooves my point that the module is somewhat silly and awkward. I must
admit though, my complaints regarding the module, can hardly be put as
frustration. I don’t allow myself to reach that stage, because I have way
more than enough stress in my life as it is. I gave the module a try, I ran
it over a period of 14 days, and a pretty stable FreeBSD server slowed down
to a crawl, similar to running Windows 2000 Advance Server on a 166MMX with
128MB RAM ← would be a accurate comparison. Furthermore, the server
CRASHED twice during the 14 days, when the server previously had uptime of
way over 60 days. That alone, was more than enough for me to have VERY
serious doubts about mod_perl, and hence my whole issue against running the
module.

I haven’t looked at FastCGI yet as you said. I do know that some mod_perl
stuff runs under it, but I didn’t have the time to play arround with it yet,
no. I’ll definately do so in the near future.

  1. Perl apps via CGI, I don’t want to use either… If I change the
    layout

Not sure what you mean here. I guess you’re doing some kind of
site-wide include stuff for your pages. But it doesn’t really matter
whether or not I understand, I think, since your other justifications
for using PHP are pretty substantial anyway.

Yeah, I’ve explained it at the begining… prepend_file and append_file is
two very nice features of PHP when you have dedicated servers for web
sites… :slight_smile:

You may want to look in $RTPREFIX/lib/RT/ for some of the code (if you
haven’t already), but I spent about five minutes looking for it and
couldn’t find the database insert stuff in there. And there are more
clueful individuals about than myself.

I saw some references to insert_ticket or something like that. They should
be defined somewhere in one of the perl modules that came with RT. I
haven’t looked yet though, I thought I’d ask first before going in to much
details to do it myself. There’s no use in re-inventing the wheel is there?
As to what you said earlier regarding getting the ticket number out of the
database… It’s probably the easiest thing to do. Both in perl and
mysql. The ticket number is stored in a auto_increment column in MySQL,
perl and PHP has built-in functions that allows you to retrieve the
auto_increment value on anydata that you insert… i.e…

$sql = mysql_query(“insert into table (column) values (‘1’)”)
$autoid = mysql_id("$sql);

I can’t remember of the tip of my head what the function’s called in mysql,
but the code looks something similar to that. I’m doing it with quite a few
other areas of my web application with great success.

me

Matt

Kind Regards,

Chris Knipe
MegaLAN Corporate Networking Services
Tel: +27 21 854 7064
Cell: +27 72 434 7582

----- Original Message -----
From: “Matt Disney” matthew.disney@fedex.com
To: rt-users@lists.fsck.com
Sent: Monday, June 17, 2002 7:27 PM
Subject: Re: [rt-users] Interfacing with RT via PHP

What are your motivations for using PHP rather than HTML::Mason?

A while back, since I wasn’t comfortable with the state of RT’s
unauthorized user interfaces, I created a PHP interface to simply email
a ticket in and then I linked to a NoAuth list of tickets in that
queue. I ditched it before we moved RT to production, though, in favor
of HTML::Mason stuff that is much better because it sits on top of the
RT API.

I’ll gladly provide the stuff I’ve done with HTML::Mason, but I’m
afraid there’s not much I can help you with as far as PHP interfaces.

Matt

Chris Knipe writes:

Hi all,

Are there anything available that’s written already to interface with
RT’s
tickets via PHP?

I’d like to have a type of system where I can inject a html form as a
ticket
into various RT queues. For example, I may have a support form on a
html
page, where the user provides his / her email address, and a detailed
description of the problem.

I’d like to then take the form data, inject it into RT, and provide
the
user
with the ticket number over the web.

Is this at all possible? Anything written for it already?

Kind Regards,

Chris Knipe
MegaLAN Corporate Networking Services
Tel: +27 21 854 7064
Cell: +27 72 434 7582

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at
http://fsck.com/rtfm

9

That’s because it’s in DBIx::SearchBuilder rather than in the RT stuff
itself.

I’ve have a look at this as well then :slight_smile:

Also, can I just say: referential integrity. Grubbing around in the
database
is just fine, so long as you’re sure you’re going to implement it in a
way
that’s not going to break things.

Which, is exactly why I thought I’d mail the mailing list, and ask about
it first before I just dig in and “break” things. This is also, why you
have development systems, and production systems… As I said previously,
if there was allready something for this (which is what I was hoping on),
why do anyone need to go and reinvent the wheel?

Maybe, if I do manage to pull this off, I’ll integrate it into a nice little
php class and contribute it to RT… I’m sure allot of people can use
something like this…

me

10

Chris Knipe:

I’m sure allot of people can use something like this…

Good grief - did your search of the archives turn up that many people
crying out in need for a PHP interface to a Perl system?

fga is frequently given answers… the best are “Date::Calc”, “use a hash”,
and “yes, it’s in CPAN” or Data::Dumper or mySQL or “check your permissions”
or NO Fmh THAT’S WRONG or “You can’t. crypt is one-way” or “yes, i’m single”
or “I think that’s a faq.” or substr! or “use split” or “man perlre” - #perl

11

Chris Knipe:

So at the end of the day, I write a complete web page, in less than 10
lines…

<? WritePageStart("page title", "page description", "keywords"); ?>

my content for the page

<? WritePageEnd(); ?>

Hi.

You’ve just demonstrated to a large bunch of people in no uncertain terms
that you have no idea what HTML::Mason is or what it does, nor have you even
looked at any of the Mason pages that make up the RT interface that you’re
attempting to replicate.

Have a nice day,
Simon

There’s no cinnamon and no lemon or orange involved. If there were, it was a
heretic who mixed it up and the mixer should be impaled on a stake and buggered
by the Shrike for two hours, then taken down and forced to rub the wounds with
the mix until death sets in. - Ingvar Mattsson cares about cocktails.

12

Hi.

You’ve just demonstrated to a large bunch of people in no uncertain terms
that you have no idea what HTML::Mason is or what it does, nor have you
even
looked at any of the Mason pages that make up the RT interface that
you’re
attempting to replicate.

No, you’re absolutely right. I haven’t.

As I said now, on multiple occasions in my previous posts, I mailed the
mailing list to find out if someone did this ALLREADY. i.e. if someone has
code allready written in PHP that can do this, so that I may not
neccessarily need to rewrite something, that has allready been written.

After mailing the list, and with the response I got from Matt, it seems that
I have to write my own application because there is no PHP interface
available currently. Fine, I have no problem with that, and I will most
definately attempt to do it. If I break RT, I reinstall it. If I can’t
manage to get the PHP working, hey - at least I gave it a try, insteading of
giving lame ass sarcastic unhelpfull comments - which happens to be more
than what I can say about you.

You happen to like HTML::Mason, that’s your right to like it, and I respect
it. I happen to like PHP, please be so decent to just try and respect it.
If you can’t, please keep your sarcastic comments to yourself as I’ve asked
in a private email to you as well now. If you don’t have anything usefull
to say, don’t say it at all please.

My suggestions to contribute to back to RT, was made in the light that
someone MAY a few months or years from now, need to do something similar.
They won’t need to go through the battle I have facing me if I contribute my
work, because something for PHP would be written allready and be available
in the open source community. It was just a gesture of trying to be
helpfull and giving back to the RT community. If they don’t want to use it,
it’s their right. If some do, I’ll be glad knowing that they’ll be
utilising things that I’ve coded and contributed.

shrugs

13

I have contemplated trying to integrate RT into our local sourceforge to
replace the php based bug tracking tool. I was thinking about running RT
in a frame but wanted to integrate the login with sourceforge and use
php code to display a list of open tickets for each user.

Michael
Michael Thompson +353 1 291 1710
RF IC Design Engineer
Silicon & Software Systems

14

I have contemplated trying to integrate RT into our local sourceforge to
replace the php based bug tracking tool. I was thinking about running RT
in a frame but wanted to integrate the login with sourceforge and use
php code to display a list of open tickets for each user.

I think it would be healthy to eventually separate RT’s UI from the
underlying engine (business logic), both to make the system more scalable and
to accomodate those that [prefer|are shackled to] a dynamic content
generation system other than HTML::Mason. I think perl is the neatest thing
since microwave ovens and mexican wrestlers, but I’ve had a lot of success
installing PHP apps. Mason can be cranky and it requires a bit more fiddling
with a coathanger to get running whereas most of my PHP app installations
didn’t require an opposable thumb.

Having said that, I believe the development resources (i.e. Jesse) are best
directed at 2.1 and 3.0; I don’t think a PHP-based UI is a Bad Thing but
those that want it shouldn’t wait for someone else to build it.

– Bob

15

a message of 31 lines which said:

Also, can I just say: referential integrity. Grubbing around in the database
is just fine, so long as you’re sure you’re going to implement it in a way
that’s not going to break things.

Yes, RT’s schema should implement referential integrity. That way,
people could develop applications in whatever language they choose,
confident that the DBMS will prevent them from breaking things.

I assume that, if it is not done, it is because of MySQL’s weaknesses?

On a general note, it seems to me that expecting to simply be able to build an
RT-based application while switching from Perl to PHP is quite like expecting
to simply be able to build a house while switching from bricks to foam rubber.

It is very common in the real world to have complicated systems
centered on a DBMS with referential integrity and applications written
in various languages.

The MySQL way to have all applications built around the same library
(to implement constraints), which means they all have to use the same
language, is incredibly outdated.

But still, people want to do crazy things, which is why SOAP was invented.
A SOAP interface to RT is being worked on; I’m sure the original poster will
be in touch with Jesse to volunteer to help its development.

Excellent idea, that's what Web Services are for. Why SOAP and not the simpler XML-RPC?
16

Stephane Bortzmeyer:

I assume that, if it is not done, it is because of MySQL’s weaknesses?

The problem is that RT isn’t primarily based on an SQL database with
an access library on top. No. RT is based on an object persistence
framework (DBIx::SearchBuilder) which just happens to use an SQL
database for the serialization backend. Similarly, MySQL just happens to
be a relatively good backend because it’s lightweight and fast.

So saying “Oh, we can just grub around in the SQL database” is missing
the point.

Why SOAP and not the simpler XML-RPC?

Simpler != better. :slight_smile:

“Having just ordered 40 books and discovered I have no change out of a grand,
I’m thinking of getting a posse together and going after some publishers. I’d
walk into a petrol station and buy lots of petrol on Monday, too, but I think
I’d get funny looks. More funny looks.” - Mark Dickerson