Until such time as the OSRS client offers ease of integration with our payment gateway and customization without changing core code (eg hooks or some other user added code methodology), we are still committed to the SF client. It allows us the most "vanilla" code base without having to go to 100% custom code or lock into the OSRS code at a specific version due to integration with our company extensions.
I am fixing a couple of bugs in the current 2.15 client now and will be posting updates on SourceForge - in either the forums section or the bugs section. This is not the same as a CVS update, but at least these bugs will be addressed. I've found 2.15 to be very stable overall, with a few small bugs: .name email forwarding handling in manage.cgi, a problem with .CA transfer initiation (no way to select what .CA domain you want to transfer from the standard transfer startup screen) and .CA display of the period and price ordered on the last page of the order process - being the most serious I've found. I'm looking at cert integration next and will look at email as well after that. I'm not sure about adding .AU support. The best of all worlds would be an OSRS client direction that embraces the SF codebase, however I'm not going to wait to move my business forward in the meantime. I'll take another look at the current version of the OSRS code to see if it's changed significantly in the last year, but it did not meet out "extensibility without changing code code" requirements last time I looked. -t on 10/2/03 11:14 PM, Ross Wm. Rader at [EMAIL PROTECTED] wrote: > On 10/2/2003 10:51 PM Peter Kiem noted that: > >> I'm looking at updating my client code again (I'm using OpenSRS-SF-2.01 >> at the moment) and I see 2.15 was released in April and there has been >> no further releases :( > > Who is interested in a new release that brings it back in line with > current functionality? > > Who is interested in contributing their own resources to helping > maintain the code? > > Zero promises, just trying to gauge interest so that we can (internally) > start to figure out how to disentangle this bowl of noodles... >