Trulia Releases an Open Source Java RETS Client
The coders reading, would be wise to take note that Trulia released some open source code today — the Trulia Java RETS Client.
It is an open source RETS data feed importer — meaning it should vastly speed up the time it takes to start working with MLS data for web and mobile applications (rather than having to build your own data importer before you can do anything).
Smart move to earn some developer mindshare, Trulia.
As I’m not a developer, I only generally get the gist of what this open source code means. If you are a coder, and want to write a geekier summary of what the code does and what it means to real estate technology innovation, shoot me a note and I’ll get you setup with an author account here. Or leave your thoughts in the comments on this post to clarify for other developers what is, & is not, here code-wise.
And remember, if you are a real estate techie with a GitHub user name & interested in discovering others, you should read this.
Seth Siegler
Posted at 11:48h, 19 FebruaryReally cool gesture to give this to the open source community.
What this is, is a library to interface with RETS servers. So you can build your app, and then interface with this library in a standardized way instead of dealing with all the nuances of establishing contact with each and every rets server. It also saves you from having to write the code to handle the nitty gritty work of importing, updating, etc.
This is a Java library so java devs can just focus on writing java and not have to learn much about rets to build an app that uses the data.
There are lots of libraries like this in other languages too. For example, Placester put out this popular one for Ruby: https://github.com/Placester/ruby-rets
Bryn Kaufman
Posted at 13:52h, 20 FebruaryI develop in PHP and JavaScript, so the Java RETS client is good for some, but not for people who prefer PHP.
Just FYI for any readers thinking of working with RETS, I have found two tools that are very valuable for my RETS development. The first one is http://www.retsconnector.com/. This gives a GUI to RETS and allows you to query a database through menu driven options. During development I constantly refer to it to test queries, see what the query syntax looks like, etc. It is just a really easy way to view RETS data.
The 2nd tool I use is https://github.com/troydavisson/PHRETS. This allows a very easy connection through PHP to RETS data.
I personally think RETS was a mistake. They should have stuck with something standard like MySQL. I like the idea of standardizing field names and data as much as possible, but this could have all been done just as easily using MySQL.
What they have done chosen to use something that very few developers are familiar with, vs. MySQL which almost all developers are skilled at.
RETS is actually is a benefit for me because it increases the cost of development a lot, because you have to either find a developer who knows RETS, and they are few and far between so more expensive, or you have to pay for your developer to learn it.
My benefit is less competition. They made it much more difficult to get at the data, and that means less agents paying for custom VOW sites.
Keep in mind I am only speaking about RETS, not IDX.
Todd A. Shipman
Posted at 18:54h, 20 FebruaryHere in lies the greatest challenge for business development – uniform access to data. As Chair of the NAR Strategic Thinking Committee – i get frustrated by the lack of vision and over use of policy and protectionism to manage outside access to the data. Granted we need to protect what is rightfully ours – but in doing so we have created a barrier to entry for developers to build industry centric tools, products and solutions for the professional and the public.