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
try.
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.
Tony
_______________________________________________
p4ruby mailing list
p4ruby perforce.com
http://maillist.perforce.com/mailman/listinfo/p4ruby
|