--- The Forwarded Message Follows ---
attached mail follows:
On Wed, 15 Jan 2003 12:27:28 -0500
Colin Viebrock <colin@easydns.com> wrote:
>>>These are provided in the API spec.
>>
>> If *COMPLETE* examples are really provided than why have
>> so many emails I've receive agreed with my position?
>>
>> The API docs *ARE* wanting, and it is debatable as to
>>what
>> should be done to fix them up.
>
>Fair enough. However, I have been able to use the API
>docs and the Perl
>code to write the PHP class. So I don't think, for
>someone who does a
>bit of work, they are that wanting.
Agreed, but I have a Tucows reseller account in order to
purchase and manage domain names. I do not have a Tocows
account because I like to "[do] a bit of work" to
implement their API spec.
My point is that *TOO MUCH WORK* is required to implement
the spec as currently documented.
I repeat, there are just a few very basic operations a
Tucows reseller will allways perform. Detail those
operations so I can get an interface up and running in 4
hours or less. If and when I need to depart from those
operations then the API doc seems more than adiquit to
quickly perfrom such customizations -- A position have
have very consistantly taken.
More to the point - I'm in the Domain Name business, not
the software buisness ...
>>>>> 2) Show all messages used for any interlocks, and
>>>>>provide as a text file
>>>
>>>I don't know what you mean by this.
>>
>> Sorry, I was refering to examplifying all the required
>> "layers", and clearly teasing out each layer and show
>>how
>> the layers depend on each other.
>I still don't follow. You have a command. You format it
>in XML. You
>encode it. You wrap it in the OPS spec (i.e. prepend a
>Content-Length
>header). You send it.
>Repeat in reverse for responses.
Not according to the 2 samples I have been provided thus
far.
I to thought your statement was "the way it is" but both
example clearly show there is an initial security dialog
which ends with a cookie. This cookie is then provided
with each command / message.
Where is this stuff documented and pulled together so one
know how the coreography is to be perfromed?????
Perhaps I am again confused???
>>>>> 3) Provide the packets after encryption as files. Thus I
>>>>>have a an
>>>>> incremental baseline from which I can verify my code.
>>>
>>>You want a TCP dump of the encrypted data? That is
>>>simply absurd.
>>
>> You are paraniod. ;-)
>>
>> What's absurbed about providing a completely detailed
>> baseline?
What possible use would this be? To check your
encryption algorhythm?
Yup!
>That's what the OpenSRS test servers, and the default
>Perl classes are
>for.
I have observed many programmers who chose not to layer
their code to simplify their debugging -- Read: devide and
conquor.
My background is in embedded systems, which do not have
hard drives, video displays, or keyboards. If I took the
"all or nothing" approach to design and testing I would be
out begging on the street.
While it's true that my PC is far easier to develope and
test on on choose not to abandone a style that has allowed
be to successfuly author extremely robust bug free (so for
-LOL!) code.
>Just try and connect to OpenSRS and communicate
>with them: if it
>doesn't work, you've got something wrong.
Yup, and I have no clue as to where the problem is.
I choose not to work that way.
>Compare the output of your class against the default Perl
>class.
Again, Perl is not a simple step for me and the purpose of
the DOCS is to be language agnostic. Your statement is
true becasue the DOCS are insufficient for the task at
hand.
>And, before you say otherwise, there are probably a
>million places on
>line where you can get instructions on getting Perl (or
>PHP) running on
>your Win98 box.
Colin, I'm in the Domain business not the software
business. I expect fast and simple support so I can make
money.
See,
http://www.netcraft.com/survey/
which cleary shows Microsoft is implemented on
approximantly 30% of the 35 million sites surveyed.
Tucows is refusing to properly support its customer base
though direct support of the Windows Platform..
>>>First, the paranoid among us will think you are going to
>>>try and
>>>reverse-hack our encryption keys. Second, if you
>>>honestly claim to be
>>>able to understand Blowfish encrypted TCP packets, but
>>>can't understand
>>>the OpenSRS API specifications ... well ...
>>
>> I don't recall *EVER* requesting or expecting a Tucows
>> reseller provide me this information.
>>
>> I do request and expect that *TUCOWS* provide *ALL OF
>>US*
>> this information for a "throw-away key" that is
>>dedicated
>> to the detailed documenation.
>
>Again, it's overkill of overkill.
Agreed, but that is what a good spec does. A good spec
address a very low standard of the "unit stardard fool"
(otherwise known as fool proofing).
>You've got the spec. You've got the default code.
>You've got all the
>tools and information required to build your own client.
1) Yes I can read
2) Yes I have code that I do not understand and whos
language is completely foriegn to me.
Perhaps I should send you some of my MatLab code to prove
my point. MatLab is a true parallel processing language
and thus virtually all coding is done without any need for
loops or while statements (but is does have them). Using
MatLab you can code multimensional pointers into your data
thus completely avoiding the need for loops.
If I coded Blowfish in MatLab I'll bet dollars to doughnut
you'd have no clue how to follow the code .... Unless of
course you have experiance with MatLab. So I could say you
are the problem when I give you the MatLab code and you
can't follow it, but I personally would never do such a
thing. I'd pull up a chair and walk you through it.
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:33 EDT