[p4ruby] Need advice re perforce - to - callcenter software connector

Tony Smith tony at smee.org
Tue Dec 18 04:01:29 PST 2007

Hi Steve,

> We have call center software/bug tracking software that we developed in
> house.  We adopted perforce about 3 years ago and all is well, except that
> we have avoided making the integration between perforce and the call center
> software.
> We are mostly a java shop and are not c/c++ guru's.  I did look for a
> perforce java api and I see some stuff out there, but it seems they are
> doing parsing of the p4client result text which I don't find reassuring,
> and I don't have a lot of hope that these libraries will be maintained over
> the long haul.  I noticed that p4ruby has been around for a while and seems
> to have active level of bug fixing, and appears to be backended with the
> c/c++ api.

I'm not sure that APIs like Dave Markley's P4Package require a lot of 
maintenance - the Perforce command line output is very stable. I've not heard 
anything bad about P4Package, and as a Java shop you might want to give it a 

P4Ruby is indeed an actively maintained package, and will continue to be so.

> So here I am.. Wondering if it makes sense to spend time writing a
> 'connector' using p4ruby, that would run all the time, periodically poll
> perforce and poll our call center software and keep the two in sync. ( i.e.
> create jobs in perforce when a call center issue is certified as a bug,
> etc.. ).   Maybe the answer is an obvious yes -- but I have been seeing
> references to p4ruby describing it as a scripting tool.

A rose by any other name, would smell as sweet... Sure, it's a scripting tool, 
but what's to say that a script wouldn't be the best way to do this. It would 
certainly be my choice - at least for a proof-of-concept; if I had stringent 
performance requirements, I might then reimplement in C/C++, but I'd start 
with P4Ruby to prove the theory quickly.


More information about the p4ruby mailing list