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.
If you've looked at this blog before, you've probably noticed that the design has changed. While I'd love to say that this was a calm and peaceful upgrade to the newest version of MovableType, it was anything but peaceful.
About 2 weeks ago, we had an issue with one of our servers which caused some data loss. Regular accounts were restored and things are pretty much back to normal, except that my personal accounts weren't in the backup rotation so a restore wasn't possible for these. I did happen to have a recent backup of the database itself but the MovableType tables were for version 3.3. The only version of MT I could find was the newest 4.1 and after looking at the table differences, it seemed like more of a challenge than I was interested in taking.
So, the blog is back up and running on 4.1 with the previous entries hand-copy/pasted into the new tables from a raw .sql file so I could at least have the posts back. I may go through and do the same with the comments but I haven't gotten there yet.
We're obviously looking at our entire backup strategy very closely and hope to have something much more complete in the works in the coming days and weeks to avoid the situation that happened while I was attending the NAR Midyear conference and trade expo. Unfortunately, due to said problems, I was only able to attend about 5 hours of the conference so I don't have the type of reaction or information I was hoping to have and post.
About 2 weeks ago, we had an issue with one of our servers which caused some data loss. Regular accounts were restored and things are pretty much back to normal, except that my personal accounts weren't in the backup rotation so a restore wasn't possible for these. I did happen to have a recent backup of the database itself but the MovableType tables were for version 3.3. The only version of MT I could find was the newest 4.1 and after looking at the table differences, it seemed like more of a challenge than I was interested in taking.
So, the blog is back up and running on 4.1 with the previous entries hand-copy/pasted into the new tables from a raw .sql file so I could at least have the posts back. I may go through and do the same with the comments but I haven't gotten there yet.
We're obviously looking at our entire backup strategy very closely and hope to have something much more complete in the works in the coming days and weeks to avoid the situation that happened while I was attending the NAR Midyear conference and trade expo. Unfortunately, due to said problems, I was only able to attend about 5 hours of the conference so I don't have the type of reaction or information I was hoping to have and post.
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.
As I'm sitting here waiting for my laptop to boot up, it's gotten me thinking. When did operating systems not become operating systems anymore?
Windows Vista has been a frustrating experience for me. I purchased a brand new laptop from Best Buy last July that came with Windows Vista Home Premium pre-loaded. I wasn't thrilled at the time knowing it was coming with Vista but I decided to try it out. What a horrible experience. After suffering through it for a few weeks, I couldn't take it any more and put Windows XP Professional on it. It worked great after that.
That whole experience opened my eyes a little. I remember a few years ago when games like FarCry were coming out and everyone was so impressed with what the game demanded out of a computer. Many people couldn't run FarCry at the time because it demanded more than what a typical PC had at the time. Once people upgraded, things were better and they could enjoy the game as it was originally intended.
When did we start treating Windows, a computer operating system, like a game? What's different between Windows Vista and FarCry is that people wanted that better, visual experience with FarCry and so they went for it. With Vista, it's basically forced on you which creates an instant negative reaction.
Brand new AMD Athlon64 X2 dual-core TK-53 1.7Ghz laptop with 1GB of RAM and it has trouble running an operating system. An operating system shouldn't be pushing the limits of what my computer can handle. An operating system shouldn't be having trouble doing the basic things that computer users use a PC for. If you can do those things well AND have a good visual experience doing it then great, but be an operating, working system first.
Windows Vista has been a frustrating experience for me. I purchased a brand new laptop from Best Buy last July that came with Windows Vista Home Premium pre-loaded. I wasn't thrilled at the time knowing it was coming with Vista but I decided to try it out. What a horrible experience. After suffering through it for a few weeks, I couldn't take it any more and put Windows XP Professional on it. It worked great after that.
That whole experience opened my eyes a little. I remember a few years ago when games like FarCry were coming out and everyone was so impressed with what the game demanded out of a computer. Many people couldn't run FarCry at the time because it demanded more than what a typical PC had at the time. Once people upgraded, things were better and they could enjoy the game as it was originally intended.
When did we start treating Windows, a computer operating system, like a game? What's different between Windows Vista and FarCry is that people wanted that better, visual experience with FarCry and so they went for it. With Vista, it's basically forced on you which creates an instant negative reaction.
Brand new AMD Athlon64 X2 dual-core TK-53 1.7Ghz laptop with 1GB of RAM and it has trouble running an operating system. An operating system shouldn't be pushing the limits of what my computer can handle. An operating system shouldn't be having trouble doing the basic things that computer users use a PC for. If you can do those things well AND have a good visual experience doing it then great, but be an operating, working system first.
For me, there are a lot of things that fit this category. Yours will undoubtedly be different from mine, but you should be able to relate to these things and understand the feelings behind it based on your own experiences.
Couple of examples: upgrading from dialup to broadband, going from regular TV to TV with a DVR, going from a hardwired phone to a cellphone, upgrading from standard definition TV to HD, etc.
Once you go, you can't go back. It just doesn't happen. The thought of it makes you twitch. Maybe some are more severe than others like living with a regular TV in a bedroom while your home theater system has a DVR, but the feeling is still there. So, what am I adding to the list?
Threaded email.
Yeah, I know. You probably think I'm crazy, but try it and you'll see what I'm talking about.
I've made several other posts about our transition to using Google Apps for email (the other services are nice, but email is where it's at) so my opinions about this are based on my experience using Gmail. There are a few small features that Google has added to Gmail which makes this concept even better, but the threaded conversation is where it's at.
I don't have the most stable sleep schedule in the world. People that I communicate often with normally don't expect me to be available at a certain time of the day and usual just base it off of how long my IM client shows I've been idle. Because of this, it might be "late morning" (after lunch) by the time I'm sitting down for the first time to get my day rolling. Often times, someone with a lot more self-discipline starts an email conversation between 3 or 4 people at the start of the day and a few emails have already circled around with thoughts or add-ons by the time I can look at it. Typically, you'd have a few emails in your inbox that you'd have to read.
If you sort by date received, you find the bottom one that's still bold and read them one by one working your way up. Because they aren't grouped by topic (or email subject), you might be reading through 2 or 3 different conversations at once, or you're reading an email and scanning up the list to find the next with a similar subject to read it.
When using a program with threading capabilities, you have 1 -conversation- to read. When you select that subject, it brings up the body of all of those emails in a neat list so you can easily read what's been said while you weren't around. Now, you can quickly reply knowing that you're up-to-date on the conversation instead of replying to an old email that doesn't need answering anymore (I can't even count how many times this has happened to me).
2 additional pieces that make Gmail's service extra-useful with conversations: 1) use of labels, and 2) quote hiding.
Labels work like a typical "folder" would in Outlook or other program, except labels are more "web 2.0". Just like you can't put a piece of paper into multiple folders at once, you can't put an email into multiple folders at once. With labels, you can assign any number of labels to an email to keep yourself organized.
Quote hiding is the big feature for me. Typically, when someone replies to your email, their message is included at the top and what you originally wrote is included in the bottom. Gmail will automatically recognize those sections of the email and hide them from your view (there's a link you can click to make them show if needed). That way, even if the "true" email back to you includes replies of replies of replies of replies, Gmail will hide those so you only see the new text and can easily read through the entire conversation.
I highly recommend you at least give it a shot. Gmail has a lot of email management features like those mentioned above that make it a great email client (I've used Gmail's web interface exclusively since changing over to Google Apps) but I know other email clients may have similar features like that as well.
If you know of another program that you like that's integrated this concept, post a comment. I'm always willing to try something new that might be better than what I've got.
UPDATE: I found a good screenshot of Gmail's system showing the threaded view along with the view of all conversations.
Couple of examples: upgrading from dialup to broadband, going from regular TV to TV with a DVR, going from a hardwired phone to a cellphone, upgrading from standard definition TV to HD, etc.
Once you go, you can't go back. It just doesn't happen. The thought of it makes you twitch. Maybe some are more severe than others like living with a regular TV in a bedroom while your home theater system has a DVR, but the feeling is still there. So, what am I adding to the list?
Threaded email.
Yeah, I know. You probably think I'm crazy, but try it and you'll see what I'm talking about.
I've made several other posts about our transition to using Google Apps for email (the other services are nice, but email is where it's at) so my opinions about this are based on my experience using Gmail. There are a few small features that Google has added to Gmail which makes this concept even better, but the threaded conversation is where it's at.
I don't have the most stable sleep schedule in the world. People that I communicate often with normally don't expect me to be available at a certain time of the day and usual just base it off of how long my IM client shows I've been idle. Because of this, it might be "late morning" (after lunch) by the time I'm sitting down for the first time to get my day rolling. Often times, someone with a lot more self-discipline starts an email conversation between 3 or 4 people at the start of the day and a few emails have already circled around with thoughts or add-ons by the time I can look at it. Typically, you'd have a few emails in your inbox that you'd have to read.
If you sort by date received, you find the bottom one that's still bold and read them one by one working your way up. Because they aren't grouped by topic (or email subject), you might be reading through 2 or 3 different conversations at once, or you're reading an email and scanning up the list to find the next with a similar subject to read it.
When using a program with threading capabilities, you have 1 -conversation- to read. When you select that subject, it brings up the body of all of those emails in a neat list so you can easily read what's been said while you weren't around. Now, you can quickly reply knowing that you're up-to-date on the conversation instead of replying to an old email that doesn't need answering anymore (I can't even count how many times this has happened to me).
2 additional pieces that make Gmail's service extra-useful with conversations: 1) use of labels, and 2) quote hiding.
Labels work like a typical "folder" would in Outlook or other program, except labels are more "web 2.0". Just like you can't put a piece of paper into multiple folders at once, you can't put an email into multiple folders at once. With labels, you can assign any number of labels to an email to keep yourself organized.
Quote hiding is the big feature for me. Typically, when someone replies to your email, their message is included at the top and what you originally wrote is included in the bottom. Gmail will automatically recognize those sections of the email and hide them from your view (there's a link you can click to make them show if needed). That way, even if the "true" email back to you includes replies of replies of replies of replies, Gmail will hide those so you only see the new text and can easily read through the entire conversation.
I highly recommend you at least give it a shot. Gmail has a lot of email management features like those mentioned above that make it a great email client (I've used Gmail's web interface exclusively since changing over to Google Apps) but I know other email clients may have similar features like that as well.
If you know of another program that you like that's integrated this concept, post a comment. I'm always willing to try something new that might be better than what I've got.
UPDATE: I found a good screenshot of Gmail's system showing the threaded view along with the view of all conversations.
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.
