Recently in RETS Category
A couple of posts ago, I introduced a programming tool that I'd thought up and started working on. The point of this tool was to help bridge a gap between familiar and the seemingly impossible.
So many times as I'm working on web applications, I end up thinking to myself "there's got to be an easier way". I've only been seriously programming for about 10 years now and my first introduction language to programming was Perl. For those that know and work with Perl, you know that "there's got to be an easier way" is a recurring theme. Perl is a very powerful language that has a lot of flexibility, but for my uses and the types of things I've found myself building, it was almost always too much. I don't need a programming language that can do everything because I don't do everything. One of the common things known about Perl is that there are many different ways to do the same thing, and it's not difficult at all to have 10 different methods for doing something that are completely cryptic to anyone other than the developer that wrote it. This is a great idea. It gives freedom of coding style, freedom of choice and flexibility in how something works. The problem is that for the majority of the time, it's simply too much for me to handle.
For the past couple of years, I've passively watched the growth of PHP as a programming language and would constantly find myself criticizing it for it's lack of flexibility or being "too easy". I've seen demos and examples of platforms like Ruby on Rails where you can create an entire blog in 5 lines of code. I like to maintain a lot of programming control in applications I write, and that's doing way too much for me (something about most of my code being put in place to reverse something that it did automatically for me just doesn't seem right). I knew Perl was making me work harder than I wanted to but I didn't know of a different language that I felt would strike the right balance for me in terms of programming control and ease of use.
About 2-1/2 years ago, I was working on a side project that involved integration with Wordpress (and then later, phpBB) which was sort of forcing me into a position of needing to know a little bit about PHP. The end goal of what I was trying to do involved tracking a user's session (in the case of phpBB, actually using phpBB's session) through a site that included iframes so the system needed to either be able to save the cookie, or, if the browser rights were too strict, at least be able to pass the session ID along with every link so every other page would still have session data. It was when I discovered PHP's use_trans_sid setting that I was hooked. With that feature enabled, PHP would automatically buffer anything I was echoing and would go back in and add the session data to the end of any link I was echoing and it would automatically add a hidden form element containing the session information to any form I was echoing so that forms could also continue the same session. This feature got really close to the "doing too much" line, but it ended up saving me a lot of time and the end result was exactly what I'd hoped for (and it did it automatically!).
There have been countless numbers of examples of the same type of situation over the last 24 months or so. number_format(), trim(), setcookie() and array_unique(), just to name a few.
So, with my new excitement about PHP only a few months old, I was sitting in the lobby of the Embassy Suites in Chicago last year on the final day of the RETS conference killing time before my 6pm train while still digesting everything that'd happened the last few days. I'd seen some demos of some nice applications and other tools, but most of them were for Windows or needed to be run as complete programs rather than smaller tools that a developer could use. I wasn't unfamiliar with working with RETS at that point because I'd written a few different internal clients in Perl, but I still couldn't say that I had a good grasp on the big picture yet. I ended up taking out a pad and pen and made a full page of notes. I was determined to find an easier way that would both make sense to me and make sense to someone else that had very little experience with RETS.
That piece of paper is what eventually became the list of goals and general structure layout of PHRETS, a free, open source PHP library for working with RETS. In working with Perl, I knew that there were a ton of Perl modules that could be used to introduce functionality to a program but I had no idea how to write one. I knew that other functions or classes could be written which would do similar things but I'd never needed to write them so I didn't know how those would be structured or designed. I knew that in order for PHRETS to be easy for someone to use, it needed to be fairly easy for me to make. I knew that if I tried to get too tricky with it, it would be too tricky for someone else to understand. I knew that if average Joe Programmer me could use it, any average Joe Programmer could.
A few weeks, I posted the latest version of PHRETS which included the last major part of RETS I'd originally set out to support (GetObject). Personally, this was a pretty big accomplishment because I finally felt like the code could be used by someone to do something useful. The code works, it manages a session successfully, it retrieves and processes metadata (data formats) correctly, it can do queries and retrieve back any type of record from a RETS 1.x server, and it can query for and retrieve back photos. It assumes as little as possible to remain as flexible as possible.
I think I've created an easier way and I encourage you, if you're even somewhat familiar with PHP, to give it a spin. It'll only take a few minutes to know if it'll be successful or not, and I think you'll find an incredible amount of flexibility using the features it has. For example, for retrieving photos, it assume nothing. You tell it what to get from the server, it gets it and returns the actual image data back to you to do whatever you want with it. If you want to put the image data into a file on your system, go ahead (you're a quick file_put_contents() away) and use whatever filenaming scheme you can dream up. If you want to send the image data to Amazon S3 for storage and serving, you can do that, too.
Development on PHRETS isn't done as things are constantly changing and improving. Additional support for versions other than RETS 1.5 are needed and the first steps towards those has already started. Additional error checking and error reporting is needed so those are being added as well. If there are features or items that you see that you'd like to suggest, please let me know. All of the information about PHRETS as available at the project site, located at http://troda.com/projects/phrets .
Look for some additional PHRETS related posts coming over the next few weeks. I'm scheduled to be part of a presentation during this year's RETS Conference in about a week where tools such as PHRETS will be showcased.
So many times as I'm working on web applications, I end up thinking to myself "there's got to be an easier way". I've only been seriously programming for about 10 years now and my first introduction language to programming was Perl. For those that know and work with Perl, you know that "there's got to be an easier way" is a recurring theme. Perl is a very powerful language that has a lot of flexibility, but for my uses and the types of things I've found myself building, it was almost always too much. I don't need a programming language that can do everything because I don't do everything. One of the common things known about Perl is that there are many different ways to do the same thing, and it's not difficult at all to have 10 different methods for doing something that are completely cryptic to anyone other than the developer that wrote it. This is a great idea. It gives freedom of coding style, freedom of choice and flexibility in how something works. The problem is that for the majority of the time, it's simply too much for me to handle.
For the past couple of years, I've passively watched the growth of PHP as a programming language and would constantly find myself criticizing it for it's lack of flexibility or being "too easy". I've seen demos and examples of platforms like Ruby on Rails where you can create an entire blog in 5 lines of code. I like to maintain a lot of programming control in applications I write, and that's doing way too much for me (something about most of my code being put in place to reverse something that it did automatically for me just doesn't seem right). I knew Perl was making me work harder than I wanted to but I didn't know of a different language that I felt would strike the right balance for me in terms of programming control and ease of use.
About 2-1/2 years ago, I was working on a side project that involved integration with Wordpress (and then later, phpBB) which was sort of forcing me into a position of needing to know a little bit about PHP. The end goal of what I was trying to do involved tracking a user's session (in the case of phpBB, actually using phpBB's session) through a site that included iframes so the system needed to either be able to save the cookie, or, if the browser rights were too strict, at least be able to pass the session ID along with every link so every other page would still have session data. It was when I discovered PHP's use_trans_sid setting that I was hooked. With that feature enabled, PHP would automatically buffer anything I was echoing and would go back in and add the session data to the end of any link I was echoing and it would automatically add a hidden form element containing the session information to any form I was echoing so that forms could also continue the same session. This feature got really close to the "doing too much" line, but it ended up saving me a lot of time and the end result was exactly what I'd hoped for (and it did it automatically!).
There have been countless numbers of examples of the same type of situation over the last 24 months or so. number_format(), trim(), setcookie() and array_unique(), just to name a few.
So, with my new excitement about PHP only a few months old, I was sitting in the lobby of the Embassy Suites in Chicago last year on the final day of the RETS conference killing time before my 6pm train while still digesting everything that'd happened the last few days. I'd seen some demos of some nice applications and other tools, but most of them were for Windows or needed to be run as complete programs rather than smaller tools that a developer could use. I wasn't unfamiliar with working with RETS at that point because I'd written a few different internal clients in Perl, but I still couldn't say that I had a good grasp on the big picture yet. I ended up taking out a pad and pen and made a full page of notes. I was determined to find an easier way that would both make sense to me and make sense to someone else that had very little experience with RETS.
That piece of paper is what eventually became the list of goals and general structure layout of PHRETS, a free, open source PHP library for working with RETS. In working with Perl, I knew that there were a ton of Perl modules that could be used to introduce functionality to a program but I had no idea how to write one. I knew that other functions or classes could be written which would do similar things but I'd never needed to write them so I didn't know how those would be structured or designed. I knew that in order for PHRETS to be easy for someone to use, it needed to be fairly easy for me to make. I knew that if I tried to get too tricky with it, it would be too tricky for someone else to understand. I knew that if average Joe Programmer me could use it, any average Joe Programmer could.
A few weeks, I posted the latest version of PHRETS which included the last major part of RETS I'd originally set out to support (GetObject). Personally, this was a pretty big accomplishment because I finally felt like the code could be used by someone to do something useful. The code works, it manages a session successfully, it retrieves and processes metadata (data formats) correctly, it can do queries and retrieve back any type of record from a RETS 1.x server, and it can query for and retrieve back photos. It assumes as little as possible to remain as flexible as possible.
I think I've created an easier way and I encourage you, if you're even somewhat familiar with PHP, to give it a spin. It'll only take a few minutes to know if it'll be successful or not, and I think you'll find an incredible amount of flexibility using the features it has. For example, for retrieving photos, it assume nothing. You tell it what to get from the server, it gets it and returns the actual image data back to you to do whatever you want with it. If you want to put the image data into a file on your system, go ahead (you're a quick file_put_contents() away) and use whatever filenaming scheme you can dream up. If you want to send the image data to Amazon S3 for storage and serving, you can do that, too.
Development on PHRETS isn't done as things are constantly changing and improving. Additional support for versions other than RETS 1.5 are needed and the first steps towards those has already started. Additional error checking and error reporting is needed so those are being added as well. If there are features or items that you see that you'd like to suggest, please let me know. All of the information about PHRETS as available at the project site, located at http://troda.com/projects/phrets .
Look for some additional PHRETS related posts coming over the next few weeks. I'm scheduled to be part of a presentation during this year's RETS Conference in about a week where tools such as PHRETS will be showcased.
In an effort to gauge interest and some early testers, I wanted to announce a project I've been working on for a few months.
PHRETS is a PHP library written for RETS. This library adds easy-to-use PHP functions for working with RETS.
My experience with RETS and real estate data in general is from a 3rd party "data consumer" role so the initial release of this PHP library is sort of targeted to that. As time goes on and more feedback is received, it may branch into different directions to offer a much more complete set of tools and features for using RETS.
I'm also fairly new to PHP myself so these functions are being written from a PHP "newbie" which should be easy for anyone remotely familiar with PHP to work with. The current code being developed is already passing the RETS compliance test so it's just a matter of cleaning things up and offering some better features and usable functions.
I've posted some introduction material at http://troda.com/projects/phrets/
If you're interested in being an early tester or being notified when I have some source code to release, sign up for the PHRETS mailing list (Google Group) and more information will be released as things develop.
PHRETS is a PHP library written for RETS. This library adds easy-to-use PHP functions for working with RETS.
My experience with RETS and real estate data in general is from a 3rd party "data consumer" role so the initial release of this PHP library is sort of targeted to that. As time goes on and more feedback is received, it may branch into different directions to offer a much more complete set of tools and features for using RETS.
I'm also fairly new to PHP myself so these functions are being written from a PHP "newbie" which should be easy for anyone remotely familiar with PHP to work with. The current code being developed is already passing the RETS compliance test so it's just a matter of cleaning things up and offering some better features and usable functions.
I've posted some introduction material at http://troda.com/projects/phrets/
If you're interested in being an early tester or being notified when I have some source code to release, sign up for the PHRETS mailing list (Google Group) and more information will be released as things develop.
First video. Brief introduction into communicating with a RETS server. Includes a basic overview of HTTP and XML, and an example RETS session.
If you have any feedback for future audio or video pieces you'd like to see made, please let me know. I'm always looking for new ideas.
If you have any feedback for future audio or video pieces you'd like to see made, please let me know. I'm always looking for new ideas.
Back about 2 months ago, I mentioned that we were looking at migrating some of our heavy email users over to Google Apps. So far, we've moved 2 large domains over to Google's service (a client with a lot of forwarders and our own company domain). Last week, we met with another company that we hope to get migrated soon. With this last domain changed over, I think we'll finally be back to "normal" when it comes to email operations. Eventually, it'd probably be ideal to have everyone using Google's hosted email service but for now, just having these 3 accounts over will be a huge improvement.
During that meeting last week, I was struck by a question that was asked.
"What all would change for our users in order for them to check their email?"
Because we've answered dozens of calls and emails from this company about email troubleshooting, we're very aware that everyone in the office checks email via Outlook (either Express or 2003).
The answer: "Nothing. We host our email in a standard format the same way that Google does. All we need to do is change a few fields one time within Outlook to point Outlook to Google instead of us and they're set. Everything functions the same from that point on."
It seemed so simple. It's something that I've often lost sight of. Running a POP3 server for email makes it so users can use Outlook, Eudora, Thunderbird, Blackberry, Opera Mail, etc. since they all work with POP3. You don't even question anymore if your email client (or email service) supports POP3. You just assume they do.
RETS, the Real Estate Transaction Standard, is the standard method used for clients and servers to talk to each other to exchange real estate data. If you have a RETS program, you access a RETS server and get what you need. That's what RETS does.
Right now, the interchangeability of RETS isn't totally there yet. Various implementations of RETS can cause issues from client to client. Various RETS workgroups are working on solidifying standards so that everyone plays by the same rules. It's hard to believe that a 150 page PDF document can have holes and remaining questions, but it does. They aren't major ones and are often easily identifiable and fixable to make it work but its hard to get something to work on the first try right out of the box.
To anyone using RETS or thinking about using RETS, follow the standard. It doesn't do any good for you to implement a POP3 server for email that requires special, unique authentication from a client because, chances are, programs won't be able to do it and people can't get their email. The advantage of investing time in implementing a standard is that it can be used as a standard and not just another crazy upgrade.
If you're an MLS with an IDX feed upgrading from FTP to RETS, I encourage you to follow the standard and implement what the standard defines. If you have extra business needs or requirements, please share those with the RETS community so those types of things can be implemented in the standard. If you decide that you aren't going to use DMQL for your queries, there won't be any RETS-compliant clients that can use your system out-of-the-box, so what's the point? Your custom server would require someone to write a custom client which involves huge time and cost investments and would require a LOT more support from your technical staff.
Compare it to email. In the near future, an agent will be able to access the MLS's data using a front-end program of their choice that gives them the features they're interested in. I like the features of Outlook. Maybe you like the features of Thunderbird more. Why should you be forced to use Outlook and why should I be forced to use Thunderbird? Maybe you're looking for a complete solution with a lot of features and I just want a simple way to search for property data for my clients.
It's an exciting time to be involved during a big change in this industry. NAR's sponsorship of RETS along with the support and services already offered by most of the major MLS vendor companies shows that it's only a matter of time.
The RETS meeting in Chicago last month opened my eyes even more to the overall picture of RETS and it's potential. Even weeks later, I'm still trying to digest a lot of the information shared and discussed. As time goes on, I'll post more and more of my thoughts of the trip.
One thing I do know is that the train ride was an experience. First time on a train (the train from Indianapolis to Chicago was changed to a bus ride so a train was only involved on the return trip) was interesting. About 5 and a half hours of Indiana countryside.
During that meeting last week, I was struck by a question that was asked.
"What all would change for our users in order for them to check their email?"
Because we've answered dozens of calls and emails from this company about email troubleshooting, we're very aware that everyone in the office checks email via Outlook (either Express or 2003).
The answer: "Nothing. We host our email in a standard format the same way that Google does. All we need to do is change a few fields one time within Outlook to point Outlook to Google instead of us and they're set. Everything functions the same from that point on."
It seemed so simple. It's something that I've often lost sight of. Running a POP3 server for email makes it so users can use Outlook, Eudora, Thunderbird, Blackberry, Opera Mail, etc. since they all work with POP3. You don't even question anymore if your email client (or email service) supports POP3. You just assume they do.
RETS, the Real Estate Transaction Standard, is the standard method used for clients and servers to talk to each other to exchange real estate data. If you have a RETS program, you access a RETS server and get what you need. That's what RETS does.
Right now, the interchangeability of RETS isn't totally there yet. Various implementations of RETS can cause issues from client to client. Various RETS workgroups are working on solidifying standards so that everyone plays by the same rules. It's hard to believe that a 150 page PDF document can have holes and remaining questions, but it does. They aren't major ones and are often easily identifiable and fixable to make it work but its hard to get something to work on the first try right out of the box.
To anyone using RETS or thinking about using RETS, follow the standard. It doesn't do any good for you to implement a POP3 server for email that requires special, unique authentication from a client because, chances are, programs won't be able to do it and people can't get their email. The advantage of investing time in implementing a standard is that it can be used as a standard and not just another crazy upgrade.
If you're an MLS with an IDX feed upgrading from FTP to RETS, I encourage you to follow the standard and implement what the standard defines. If you have extra business needs or requirements, please share those with the RETS community so those types of things can be implemented in the standard. If you decide that you aren't going to use DMQL for your queries, there won't be any RETS-compliant clients that can use your system out-of-the-box, so what's the point? Your custom server would require someone to write a custom client which involves huge time and cost investments and would require a LOT more support from your technical staff.
Compare it to email. In the near future, an agent will be able to access the MLS's data using a front-end program of their choice that gives them the features they're interested in. I like the features of Outlook. Maybe you like the features of Thunderbird more. Why should you be forced to use Outlook and why should I be forced to use Thunderbird? Maybe you're looking for a complete solution with a lot of features and I just want a simple way to search for property data for my clients.
It's an exciting time to be involved during a big change in this industry. NAR's sponsorship of RETS along with the support and services already offered by most of the major MLS vendor companies shows that it's only a matter of time.
The RETS meeting in Chicago last month opened my eyes even more to the overall picture of RETS and it's potential. Even weeks later, I'm still trying to digest a lot of the information shared and discussed. As time goes on, I'll post more and more of my thoughts of the trip.
One thing I do know is that the train ride was an experience. First time on a train (the train from Indianapolis to Chicago was changed to a bus ride so a train was only involved on the return trip) was interesting. About 5 and a half hours of Indiana countryside.
Brief overview of the business cases for RETS and what advantages it offers from an IDX services perspective.
If you can think of other advantages that I missed, please post it in the comments for others to see.
Loading audio player...
If you can think of other advantages that I missed, please post it in the comments for others to see.
Loading audio player...
First audio piece of the series. Ignore the mention of video towards the beginning. I haven't gotten that far yet. Please post any comments or feedback.
Technical Introduction to RETS (my perspective)
Loading audio player...
Technical Introduction to RETS (my perspective)
Loading audio player...
I hope these are found to be useful. They don't take long to make but I think they're good information pieces for people interested in the topics. I'll keep adding these as they're created. The first 2 I've done are simply audio pieces (the first one mentions a video but I haven't gotten that far yet) but some of the future ones will probably be videos to help visualize what I'm talking about.
Hope you enjoy. If you have any comments or feedback, please post.
Hope you enjoy. If you have any comments or feedback, please post.
Hotel reservations made, train ticket booked and paid for, and everything else coming together. I'm working on getting some of lingering things done before I leave town for a few days. Starts on Wednesday and ends Friday evening.
This'll be the first RETS meeting I've attended and, really, is the first time I've had anything other than text conversations with people involved with RETS. I'm not sure what to expect and I have no idea how many other people are going to be there. I know the Inman conference was recently so there may be people who don't want to come to both. Who knows. We'll see.
I'm not much of an idea person but there are a lot of things about RETS that strike me a little odd so I hope to bring up some good points during the smaller discussions (assuming I don't chicken out and keep my mouth shut). At this point, I'm not that interested in the RETS2 Payload discussions (or really RETS2 that much overall) yet so I'll probably be at most of the other sessions, including ones I probably won't have anything to contribute to.
I've thought of some more RETS-related content I can put together to hopefully help other people getting a fresh start with RETS. I was recently able to help a developer from Massachusetts that opened my eyes to a lot of things. I'm not nearly as knowledgeable about RETS as probably most of the other people at this meeting I'm going to, but I'm also not brand new to it either. I think I'm in a unique position to be able to bridge the ever-increasing gap between those 2 sides and have the tools and knowledge to pull it off.
Stay tuned. We'll see how this goes.
This'll be the first RETS meeting I've attended and, really, is the first time I've had anything other than text conversations with people involved with RETS. I'm not sure what to expect and I have no idea how many other people are going to be there. I know the Inman conference was recently so there may be people who don't want to come to both. Who knows. We'll see.
I'm not much of an idea person but there are a lot of things about RETS that strike me a little odd so I hope to bring up some good points during the smaller discussions (assuming I don't chicken out and keep my mouth shut). At this point, I'm not that interested in the RETS2 Payload discussions (or really RETS2 that much overall) yet so I'll probably be at most of the other sessions, including ones I probably won't have anything to contribute to.
I've thought of some more RETS-related content I can put together to hopefully help other people getting a fresh start with RETS. I was recently able to help a developer from Massachusetts that opened my eyes to a lot of things. I'm not nearly as knowledgeable about RETS as probably most of the other people at this meeting I'm going to, but I'm also not brand new to it either. I think I'm in a unique position to be able to bridge the ever-increasing gap between those 2 sides and have the tools and knowledge to pull it off.
Stay tuned. We'll see how this goes.
There's so much more to RETS than can be described here and there are many possible applications for it that many don't even realize yet.
RETS is backed by the National Association of REALTORS® and is here to stay. Work is continuing on RETS 2.0 which has many enhancements over the 1.x versions of RETS.
For more information about RETS and how to get started, visit www.rets.org.
Other links for relevant information mentioned here:
- StandardNames
- RETS-compliant clients
- RETS-compliant server vendors
If there are other questions you have that you can't find answers for, email me and I'll try and point you in the right direction.
RETS is backed by the National Association of REALTORS® and is here to stay. Work is continuing on RETS 2.0 which has many enhancements over the 1.x versions of RETS.
For more information about RETS and how to get started, visit www.rets.org.
Other links for relevant information mentioned here:
- StandardNames
- RETS-compliant clients
- RETS-compliant server vendors
If there are other questions you have that you can't find answers for, email me and I'll try and point you in the right direction.
RETS has a lot of benefits but let's talk about the big ones and the problems they solve.
How do I know how to connect to get the data I need?
With RETS, all you need to know from the MLS is the RETS login URL, your username and your password. From there, you can learn everything else on your own almost entirely using code if you want.
It seems like using a complex system would be harder for an MLS to support. How is this easier?
In most cases, if you have a question about how to log into a typical FTP server and process their data, you'll end up talking to someone that didn't actually create it so your answers will be scattered (if you get an answer at all). Maybe someone went through the MLS software and enabled new fields to be included in the feed. You can't expect everyone at the MLS to know about this so you may be disappointed with the answers you get.
With RETS, it is a more complex system, but it's well documented and as long as both the client and the server are compliant with the standard, you should have little trouble getting setup. You don't need to request help or documentation from them because it's either online (at the rets.org website) or available through the RETS server you're connecting to.
Logging in is pretty easy but then what do I do?
The process is very similar to what you'd do when you first get FTP access to an IDX feed for the first time. Once you login, you figure out what information is available. In RETS, these are called Resources. Once you request the Resources, you'll get back a list of information types that you can learn more about. From there, you can learn about the format of that data and learn how to search it for what you need.
Don't I need to understand the query language used by the MLS's database software to be able to get information?
Nope, that's a major benefit of RETS. RETS uses it's own query language and, when combined with StandardNames, allows you very easy access to pull property information that you need. The RETS server translates your RETS query into something it can understand, pulls the information out of it's database (the way it knows how) and morphs it into the RETS format so it's easy for you to understand when it sends it to you.
If RETS is so powerful and is truly live access to the data, can't I just have a website that connects directly to the RETS server instead of downloading a copy of the data locally?
Sure, and there are products that exist that do just that. Your website might have search criteria for listing price and number of bedrooms. That information could be put into a RETS query, sent to the RETS server, and the response could be displayed back to the user of the site.
The problem is that your MLS could catch onto what you're doing and could limit the amount of information you can pull (using queries) from the RETS server. They may even revoke your access to their system. In most cases, when you want to use data on your website, it's best to download a local copy of the data and access it from there.
You keep mentioning building a website using RETS access. Aren't there other applications for this system?
Absolutely. Having multiple MLS's in the same geographical area provides the potential for those MLS's to share property information between them so that agents in those areas have more to show potential buyers and provides agents with more exposure for their sellers. This is just 1 example. There are many others.
I really, really don't like the MLS software the MLS has for me to access it. Does RETS do anything in that situation?
In short, yes. If your MLS has a RETS server that you have access to, you could use any RETS-compliant program (called RETS clients) to access that data. This introduces more options for agents and brokers because they aren't tied to single user interface.
There are drawbacks, however. In most cases, the MLS software offers a lot of features. So far, it's difficult for a RETS client to offer the same features that the MLS might be able to offer through their own software because their software is made specifically to work with their data in their area. Work is continuing with RETS to try and introduce more capabilities for information sharing.
(continued in Part 6)
How do I know how to connect to get the data I need?
With RETS, all you need to know from the MLS is the RETS login URL, your username and your password. From there, you can learn everything else on your own almost entirely using code if you want.
It seems like using a complex system would be harder for an MLS to support. How is this easier?
In most cases, if you have a question about how to log into a typical FTP server and process their data, you'll end up talking to someone that didn't actually create it so your answers will be scattered (if you get an answer at all). Maybe someone went through the MLS software and enabled new fields to be included in the feed. You can't expect everyone at the MLS to know about this so you may be disappointed with the answers you get.
With RETS, it is a more complex system, but it's well documented and as long as both the client and the server are compliant with the standard, you should have little trouble getting setup. You don't need to request help or documentation from them because it's either online (at the rets.org website) or available through the RETS server you're connecting to.
Logging in is pretty easy but then what do I do?
The process is very similar to what you'd do when you first get FTP access to an IDX feed for the first time. Once you login, you figure out what information is available. In RETS, these are called Resources. Once you request the Resources, you'll get back a list of information types that you can learn more about. From there, you can learn about the format of that data and learn how to search it for what you need.
Don't I need to understand the query language used by the MLS's database software to be able to get information?
Nope, that's a major benefit of RETS. RETS uses it's own query language and, when combined with StandardNames, allows you very easy access to pull property information that you need. The RETS server translates your RETS query into something it can understand, pulls the information out of it's database (the way it knows how) and morphs it into the RETS format so it's easy for you to understand when it sends it to you.
If RETS is so powerful and is truly live access to the data, can't I just have a website that connects directly to the RETS server instead of downloading a copy of the data locally?
Sure, and there are products that exist that do just that. Your website might have search criteria for listing price and number of bedrooms. That information could be put into a RETS query, sent to the RETS server, and the response could be displayed back to the user of the site.
The problem is that your MLS could catch onto what you're doing and could limit the amount of information you can pull (using queries) from the RETS server. They may even revoke your access to their system. In most cases, when you want to use data on your website, it's best to download a local copy of the data and access it from there.
You keep mentioning building a website using RETS access. Aren't there other applications for this system?
Absolutely. Having multiple MLS's in the same geographical area provides the potential for those MLS's to share property information between them so that agents in those areas have more to show potential buyers and provides agents with more exposure for their sellers. This is just 1 example. There are many others.
I really, really don't like the MLS software the MLS has for me to access it. Does RETS do anything in that situation?
In short, yes. If your MLS has a RETS server that you have access to, you could use any RETS-compliant program (called RETS clients) to access that data. This introduces more options for agents and brokers because they aren't tied to single user interface.
There are drawbacks, however. In most cases, the MLS software offers a lot of features. So far, it's difficult for a RETS client to offer the same features that the MLS might be able to offer through their own software because their software is made specifically to work with their data in their area. Work is continuing with RETS to try and introduce more capabilities for information sharing.
(continued in Part 6)
