--- The Forwarded Message Follows ---
--- Begin Message ---
On Wed, 15 Jan 2003 12:27:28 -0500
Colin Viebrock <[EMAIL PROTECTED]> 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.
--- End Message ---
