Behind Yadis

Posted by santosj on June 20, 2006

Keeping it Simple, isn’t always simple.

I’ve been doing some tests on sending and receiving XML using a HTTP method. Doing so, I’m starting to learn how difficult creating the technology and how much work went behind Yadis.

You can’t just create a standard half assed and expect people to use it. The tests don’t use this principle currently, but they will, I’m writing my standard as go kind of thing and will release a final version when the tests have concluded.

The API for Yadis is very easy and simple to use. The same isn’t true for the backend. The backend is hell, unless you are a l33t master.

Case In Point

PHP DOM says that using the loadHTML() function won’t validate the data, it does. In retrospect, I probably should have tried setting validateOnParse to false. I thought the default was already false. Have to do some research in that.

Using the DOM method to get the Meta data would be far better method than using regex, however DOM was meant for XML and some HTML doesn’t conform well to standards. It will ‘work’ for browsers, but DOM class is going to say, “This HTML is not well formed. BOOM!” Not good when you absolutely have to correctly get the meta tag every time.

Redirection

One of the nice things that I thought was neat about the standard is that if you don’t have PHP support, you can still benefit from Yadis. Yadis standard supports redirection and will redirect until it gets to the Yadis document. Therefore, if you are a cheap server that doesn’t give you PHP/Mysql support, you can set the meta tag to a server that supports yadis. However, I fail to see the use of linking to a server that doesn’t support PHP, you should just link to the server that does support Yadis.

It is more for when you don’t want to link directly to the Yadis document. It is easier to change the meta tag when you change servers than to update the sites that you linked directly to the document. The standard smartly allows linking to the server, but it is has more to do with OpenID already supporting that feature.

It make senses and makes the standard extremely strong.

Yadis Flaws

  1. Requires Yadis Content Type

I haven’t filed this suggestion to the main standard developers. I have been planning to do so, but I don’t think it is much of an issue currently.

In my implementation, if you say the content type is just ‘text/xml’, then awesome, I’ll still parse it. Hell, I’ll do one more and try to parse the XML as long as it conforms to the standard. I’m just that nice of a guy!

Actually, I think they just did that to add in a protection for parsing. You should check to see if the element exists before using it anyway, so the point is mute. If they wanted people to that, they should also call for a new extension for the file that holds the data. The Yadis Library authors may already do this, but I suspect that many don’t since it is part of the standard.

It is hard to set the content-type unless you use a programming language to set the header for it. The XML parsers may also check the XML for the content-type, instead of the Header information.

  1. API: No Iterator

In my implementation, I’m going to use the PHP 5 Iterator support for getting the services and I’m also going to allow searching for a search (think it is part of the Yadis API in the hasService method, but it has been a few days since I’ve looked at that part). The PHP 4 classes can be used in a while loop however, but I’ll rather use foreach thank you.

All of the implementations that I could find are written for PHP 4 with PHP 5 support. Okay, that allows me to give PHP 4 the finger and develop using all of the PHP 5 features. If someone wants PHP 4, they can use the other libraries.

Possibly Related Posts:


Projects

Comments are closed.