We were attracted to the SF client by its architecture (which is far superior and better planned than the main client). The eventual lack of commitment to the SF client prompted us to design our own in PHP. I say design not build because domains are currently just a value add for us, so we have been slow to build it, using an older version of the SF client for bulk orders and the RWI for onesie-twosie orders.
My feeling is that the SF client is better positioned for adding services and new tld's too.
Of course, I'm looking at it from a programming standpoint (hey, its dev-list here :) -- OpenSRS has to consider who is using the client(s), what they do with them, and which customers OpenSRS is catering to. My guess is that the biggest clients can and do build their own clients, whereas the small ISP and development shops prefer to slap up a copy of the "best supported" client (right now the OSRS main client).
We also investigated other registrars who mainly support resellers and found that they had less advanced, though easier to use/integrate API's - mainly web-based (format a URL and fetch it); so if OpenSRS is concerned with attracting (or scaring away) new customers who are interested in ease of integration, the SF code should warrant a second look.
-Russ
At 10:29 AM 9/30/2003, myOstrich Domain Manager wrote:
Though I have no experience with the most recent OSRS client, in the past, my experiences were not terrific.
Not to be too judgemental, but the OSRS client had the appearance of being thrown together to get something out there - and then repeatedly hacked to add capability.
The SF project had an architecture, robust error handling, easy extension through the hooks process (though more documentation and example are really needed here) and most importantly at the time for me, easy integration with a payment gateway and my in-house database (again, through hooks, not code hacks or changes to core code).
There are certainly problems with the current SF client code (taking nothing away from what Paul has done to date), and though again I don't have experience with the current release of the OSRS code for domain names, the code for the email client is pretty basic. Error handing is very rough, and often sends me to an error.html page with a cryptic response from the server, where I have to then use the back button to get back to the application, and often need to re-enter all the form data for that page (yuk). I don't know if the domain code shares this behavior, as I have not installed it in many releases. Perhaps I should install it and put it through it's paces, but time is never on my side it seems.
I was under the impression that one of the that Joey deVilla was hired to do was exactly this one - to get through the client morass and come up with one client direction.
I'm happy to help in any way I can, as I feel like I'm caught between a rock and a hard spot all the time here, and will be working on a few critical problems in the SF client over the next week or so in order to go online with it. I'd really rather put my energies into value-added selling rather than code up what should be basic, stable features in the client application.
Thanks,
-Tim
on 9/30/03 9:20 AM, Ross Wm. Rader at [EMAIL PROTECTED] wrote:
> On 9/29/2003 2:51 PM WebWiz noted that: > >> obviously, given the most recent posts from OpenSRS, I >> guess I'll be using the OSRS code rather than the SF client > > To be clear, what Joey said (what we've said) is that the OSRS client is > the safest bet because we're trying to figure out what our best option > is. I pulled the dev resources from the SF project a) because it was > constantly in catch up mode b) at the time, there was no apparent > committment to merge the two branches (or kill one in favor of the > other) and given all of this, c) I thought that resourcing our blogging > project was a better economic bet. > > Figuring out the answers to this question is something I want to get to > fairly quickly so that we only have one answer to give. > > Again, if you have any input as to which way we should go, let's hear it. >
