[bop-devel] Python gateway module

[Ivan Kohler]

On Wed, Aug 23, 2006 at 08:54:21PM -0700, Jo Rhett wrote:
> On Aug 23, 2006, at 5:20 PM, Ivan Kohler wrote:
> >>Given that BOP is roughly halfway done
> >
> >Personally, I thought it was reasonably complete when I took it over
> >four or five years ago, and I've always felt it needed maintenance,  
> >some
> >refactoring/cleanup and refining rather than any sort of major
> >development.  What did you have in mind?
> 
> Well frankly, a more unified interface would be good.  I'm honestly  
> not a user of this.  I developed our own common interface to all of  
> the different payment gateways we support.  When I found that there  
> was a open source project trying to do this, I jumped on it ready to  
> get out of the business of being the sole maintainer of ours.
> 
> So I have testbeds with both of ours side by side, and I am still  
> intending to go forward on switching over.  But the "clear good  
> reason" for doing it has fallen by the wayside when I realized that  
> using the BoP modules required more if/then/else around which payment  
> gateway we were using than our own stuff did.  Not much more, but no  
> clear advantage in making the change.

FWIW, I don't have any if/the/else logic for different payment gateways 
in my use of B:OP.  You may want to get involved more and at least let 
us know the specific differences that you're running into here.

> That said, you've got better support for shipping options, the  
> security codes, and stuff that I still haven't gotten around to  
> implementing.  So I still need to go forward.
> 
> bleh, not an answer is it?  Sorry.  I guess I'm saying that to make  
> BoP a real obvious no-brainer, it really should do a better job of  
> hiding the destination API from the application.  (which is hard for  
> all of the human-source and silly banking stuff that I mentioned  
> before, but I think it could be done better)

A better job in what way, specifically?  As I said, my application 
doesn't have any idea about the destination API, and I've used it with 
dozens of gateways.  If your specific usage isn't finding things 
sufficiently abstracted by B:OP, it would be great if you could tell us 
specifically what problem with that you're running into with that rather 
than speak about it only general terms.

> [...]
> 
> But personally, I'd rather toss another major revision into the BoP  
> stuff and really hide as much of the "which payment module are you  
> using" in the modules, and less in the application.  It will require  
> a major version change because the invocation methods would probably  
> all change, etc and so forth.

A new major version and API change seem to be a common request, but I'm 
having trouble understanding what we gain by this.  Why do the 
invocation methods have to all change?  I would really prefer to support 
new functionality in a backwards-compatible fashion.

-- 
_ivan