On Wednesday 20 April 2005 08:56 pm, Brad Thompson wrote:
> Dear Zeljko Dimic,
>
> Thank you for your upbeat message today.  However, it appears you have
> missed the point expressed below and on other repeated postings.
>
> The message is... *Your customers are trying to tell you to provide a
> documented and open system that we can work within.  NOT language
> specific.  NOT platform specific.*  Just open and clearly documented.
>
+1 

Language specific bindings mean nothing to me, unless you have them in the 
language I am using, which may change. 

I don't understand what appears to be this resistance to creating decent XML 
schemas for the messages that can be posted to a url and standard xml schemas 
for the responses.

> XML is the current standard that meets those requirements.  Every
> programming language and operating system has a wealth of methods, tools
> and applications to process effectively designed XML.  Why is Tucows
> resisting this standard?
>
Take a look at the enom api. A brief look at it is basically what I've been 
talking about ... although I don't know if they have any actualy schemas, but 
the XML itself makes a LOT of sense compared to what I've seen with the 
Tucows XML. 

I'm not saying duplicate the enom api btw.. :-) 

I like Tucows and I want to stay with them, but we've outgrown the perl client 
and it's time we write our own. And to do that I want ... no need ... a sane 
API.

> We are all big boys and girls out here and have the professional skills
> and talents to write our own applications as needed by our businesses.
> Your job is to be an open and easily used service.  If you don't, other
> providers will.  That's the bottom line.
>
> Brad Thompson
>
> [EMAIL PROTECTED] wrote:
> >> [...] well documented XML schemas for all types of requests and
> >> responses. [...]
> >
> > And that would work for me as well, but I would not mind just "flat
> > filing" it as I described previously.
> >
> > And one thing to add to this is that the API response *MUST* return
> > verbose error response and not just flip it's middle finger at me ......
> > Human errors and mistakes are envitable and Tucows end's logic does
> > not have to map everything into a single terse useless response, give
> > every error endpoint it's own unique response even if' it's just a
> > number for which there is a document listing out all the error code
> > numbers and what they mean.
> >
> >> Creating php bindings or perl bindings or any other language specific
> >> bindings is just catering to 'loudest crowd' of programmers.
> >
> > Agreed 100%
> > _______________________________________________
> > domains-dev mailing list
> > [email protected]
> > http://discuss.tucows.com/mailman/listinfo/domains-dev

-- 
Edward Muller - Interlix
[EMAIL PROTECTED]
417-862-0573
PGP Key: http://interlix.com/Members/edwardam/pgpkeys

Attachment: pgpJ9qjcX3CbV.pgp
Description: PGP signature

_______________________________________________
domains-dev mailing list
[email protected]
http://discuss.tucows.com/mailman/listinfo/domains-dev

Reply via email to