Hi Robert - A few points:
- documentation is always a challenge - I will not defend the current docs too much, except to say they (believe it or not) are better then they used to be (notably better than when they did not exist... :) ) - we are happy to take specific feedback, and are committed to continuing to evolve them - again, the more specific your suggestions, the likelier we can action them - I would note that many people have been able to get things working on different platforms - if you are not getting responses to your questions, we can correct this - just drop us a note off-list with your ticket numbers and we can follow through - protocol questions can be trickier as they are not as common, so our response time is likely slower - posting protocol questions to this list can be a quick way to get the info you seek, as many here have worked it out already, or are "in the know" Thanks for taking the time to write! Regards, sA At 03:21 PM 2/12/02 -0500, Robert Dale wrote: >I understand where Chris Love is coming from. I think OpenSRS should, >first and foremost, provide a well-documented protocol to their service. >Then they should provide an implementation. > >However, the documentation for the protocol is extremely poor and scattered. >The client _protocol_ docs concentrate on their _implementation_! > >Now, I work for a Java shop. That is why the perl API is no good for us. >Why perl may not be acceptable for others is of their own reasoning. But, it >doesn't really matter why. There would be no issue if the protocol were >properly documented. Protocols should be language agnostic! They're for >cooperation. > >Most of my questions have been met with silence, but I'm used to that since >most of my work deals with unexplored terrirtory and having to find answers >for myself. > >OpenSRS once emailed emailed 'us' asking how to make their >client access better. I wrote back with something along the lines of >separating their current docs into a Client API (the perl implementation) >and a Client Protocol (with better details and examples). It's been >months and haven't seen anything yet. I would even be willing to volunteer >on this effort since I would like to fully comprehend the entire protocol. >Instead I have to rely on my own notes. > >My biggest concern isn't the initial barrier to figuring things out, but >rather when small changes on their side become mountains on my side. >So, if it takes me 1 man week of work to write a java client, that's fine. >But when each new feature takes an additional man week to solve, then that >becomes a serious issue. Should that time ever occur, I believe we would >seriously consider a new registrar. > >-- >Robert Dale > >digital mission llc > > >On Tue, 12 Feb 2002, Christopher Hicks wrote: > > > On Tue, 12 Feb 2002, Chris Love wrote: > > > PERL is simply not an acceptable language for us and many others to > > > work with. > > > > Why? > > > > -- > > </chris> > > > > "Outside of a dog, a man's best friend is a good book. > > Inside of a dog, it's too dark to read." - Groucho Marx > > Scott Allan Director OpenSRS [EMAIL PROTECTED]
