RealTown's RealTalk

As usual, Saul, you made hay... good for you...

On another note, our Rhode Island MLS is moving from FTP delivery of the IDX
data to RETS Connections... based on the recommendation of the NAR
Technology group. Of course, virtually all RETS Connectors are in BETA stage
of development, which means that delivery of the data will be most likely
unstable, untested, and unreliable. They have given us a month and a half to
implement the changes...

The changes of course are unbudgeted, unexpected, and come at a time when
resources should be conserved, rather than expended on useless and untested
technologies.

RETS technology provides no enhanced functionality over the tried and tested
FTP method, and so a transition to it seems ludicrous to me.

I am not sure that many of us know that this technology is still in Beta,
and that it is therefore untested and unproven. I also am not sure that many
of us know that there is virtually no enhancement to service because of
this. None.

The change for us is costly, as we use a custom built IDX interpreter and
display system. This means that we are now required to rewrite code that was
tried and true, in order to accommodate BETA Technology, which offers no
enhancement of service. For our firm, which generates 85% of our business
via leads from the web, relying on BETA technology which provides no
advantage and costs much to implement, is beyond ludicrous, it is in fact
dangerous to our business.

I hope others look into this, and provide feedback to their MLS (especially
the Statewide MLS in Rhode Island)

Have a great day!

Best regards,

Paul Silver
Focus Professionals, Inc.

Paul,

I had to stop and comment a bit on your feelings about RETS. To say that "RETS Connectors" are in beta stage is not accurate. The RETS standard has been around and in use for the last decade. It moves a tremendous amount of data on a daily basis in our industry. When the MLS Technology committee made its recommendation to require that all REALTOR MLS organizations provide RETS, the percentage of MLS' already offering RETS was 80% or greater. Since that time, that percentage has grown. At the recommendation of RESO (the Real Estate Standards Organization, in charge of the RETS standard), the MLS Technology committee pushed back the required date from June 2009 to December 2009 to allow those systems not quite ready, to get ready. So, our industry has had something like 18 months to accomodate this change. I also want to point out that the requirement to provide RETS does not mean that an organization cannot provide FTP. Whether any particular MLS provides FTP is a business decision they must make.

Remember that RETS is an open standard, just like FTP. Just like FTP, there are many different programs out there that implement the protocol, some better than others, some designed to provide one way to access the data and some a different way. Many of those programs and toolkits are designed to replace FTP as a transport mechanism. So that your website vendor can make a RETS query and end up with a familiar looking flat file. Of course, that only begins to scratch the surface of what RETS can do.

I don't want to comment too much on your particular system, but the MLS technology provider for Statewide MLS, Marketlinx, has been involved in the RETS standard since the beginning and is a leader in the field.

I should also say that I do sit on the RESO board, though my statements here should not be taken as "official" statements of RESO.

thanks,

Paul Hethmon

Clareity Security

Paul,
I had to stop and comment a bit on your feelings about RETS. To say that
"RETS Connectors" are in beta stage is not accurate. The RETS standard has
been around and in use for the last decade. It moves a tremendous amount of
data on a daily basis in our industry. When the MLS Technology committee
made its recommendation to require that all REALTOR MLS organizations
provide RETS, the percentage of MLS' already offering RETS was 80% or
greater. Since that time, that percentage has grown. At the recommendation
of RESO (the Real Estate Standards Organization, in charge of the RETS
standard), the MLS Technology committee pushed back the required date from
June 2009 to December 2009 to allow those systems not quite ready, to get
ready. So, our industry has had something like 18 months to accommodate this
change. I also want to point out that the requirement to provide RETS does
not mean that an organization cannot provide FTP. Whether any particular MLS
provides FTP is a business decision they must make.
Remember that RETS is an open standard, just like FTP. Just like FTP, there
are many different programs out there that implement the protocol, some
better than others, some designed to provide one way to access the data and
some a different way. Many of those programs and toolkits are designed to
replace FTP as a transport mechanism. So that your website vendor can make a
RETS query and end up with a familiar looking flat file. Of course, that
only begins to scratch the surface of what RETS can do.
I don't want to comment too much on your particular system, but the MLS
technology provider for Statewide MLS, Marketlinx, has been involved in the
RETS standard since the beginning and is a leader in the field.
I should also say that I do sit on the RESO board, though my statements here
should not be taken as "official" statements of RESO.
thanks,
Paul Hethmon

---

My own software company built our websites. We see no need to move from a
truly open standard of FTP to a so called standard that is particular to the
real estate industry, and which provides no benefit over standard FTP. Being
a standard for a century would not mean that RETS Connectors are not in
BETA... please find me a RETS connector that runs on Linux servers that is
not in BETA...? I find none... even Windows server RETS connectors are in
Beta, as far as I can see... this is because despite being a standard for
years, no one has actually developed tools for this that are beyond Beta
stages of development. With good reason: there are no technological
advantages to it. I own a software company, and have had my developers go
through this... none can see a point to it... most call it ludicrous. FTP
has been proven, is not restricted to one industry, and is far less costly.

Sounds to me that the third party companies like this, and NAR likes this,
but there is no benefit to subscribers, at least as far as we can see.

Please also advise me as to what technological benefits there are to a RETS
technology over FTP, which is much older, proven, and less expensive?

As far as the Industry having time to adopt the standard, we, as IDX
subscribers, in RI, were told of the change 2 weeks ago, and given a month
to make the change... to me, that is very short notice, requires a rewrite
of our software, at a cost of some $3500, unbudgeted, in this current
market...

There are no advantages to it as far as I can tell, and if NAR wants to
enforce a standard that is really a non-standard, with no advantages
technologically, then let them pay for the changes we must incur... I see no
basis to make this change, especially when the connectors are in beta...

Have a great day!

Best regards,

Paul Silver, Esq.
Focus Professionals, Inc.

Paul,

Good comments, let me respond to some specific points you make.

>My own software company built our websites. We see no need to move from a
>truly open standard of FTP to a so called standard that is particular to the
>real estate industry, and which provides no benefit over standard FTP. Being
>a standard for a century would not mean that RETS Connectors are not in
>BETA... please find me a RETS connector that runs on Linux servers that is
>not in BETA...? I find none... even Windows server RETS connectors are in

I use the jretsc library myself. Written in Java, it runs on any JVM including on my Linux boxes I run. I've been using it for several years now including with the Statewide RETS server.

>Beta, as far as I can see... this is because despite being a standard for
>years, no one has actually developed tools for this that are beyond Beta
>stages of development. With good reason: there are no technological
>advantages to it. I own a software company, and have had my developers go
>through this... none can see a point to it... most call it ludicrous. FTP
>has been proven, is not restricted to one industry, and is far less costly.

FTP is File Transfer Protocol, no secret there. I started using it in 1991, even helped update the RFC's in the late 90's. From a technology point of view, FTP is dead simple. Move a file from point A to point B. The only thing it cares about as far as the file is concerned is whether its text format or binary format. Text format means it should translate the end of line character from the host file system to the network standard. It does have its problems though, its insecure in that it transmit login credentials in clear text. You can get around that by using one of the secure variants, but those are not as available. It also has the problem of the server making the data connection back to the client by default. Passive mode helps with that.

From the point of view of a former MLS software vendor (I was with Marketlinx early on), we had a hard time managing FTP on a Windows based server. It didn't integrate well into the rest of the systems and it took a seemingly tremendous amount of staff time to maintain the multiple file formats that everyone wanted. Pictures themselves were pure horror.

RETS is a data transmission standard. It defines a protocol, and most importantly metadata that allows software to figure out what data is available and what type that data is. It was developed as a machine to machine protocol, not human to human. With RETS, i can query the metadata and find out there are 97 fields in the Residential data. I can find out what each of those fields is. I also like the fact that as a consumer of RETS data, I am in control on when I get those updates. I have a lot of RETS feeds where I make queries every 5 minutes to update my data. But I don't have to get the multi-megabyte file since I only ask for the data that changed in the last 10 minutes each time. Once I get that data, it's already formatted for me to consume. I dynamically grab the fields I want (and only those fields) and feed those directly into my systems.

>Sounds to me that the third party companies like this, and NAR likes this,
>but there is no benefit to subscribers, at least as far as we can see.

I would say that the reasons above are why vendors like it. Vendors are out there to provide a service to the real estate market. If they can do it in an efficient manner, then they win and their customers win. RETS was developed to allow vendors to have a common standard to exchange data. So you don't have a different way to obtain data on every MLS system you need it from.

>Please also advise me as to what technological benefits there are to a RETS
>technology over FTP, which is much older, proven, and less expensive?

Beyond what I've already mentioned, it has a great benefit the first time you go to get data from more than one RETS server. The only thing that changes is that in MLS A, the price field is ListPrice while in MLS B, the price field is LP. You map the source system names to the fields you need for your system. You might also look at the syndication schema standard. That was developed by RESO in conjunction with Google, Trulia, Zillow and a few others. It defines a standard data schema with around 50 of the most common data points. If you can get that schema, you do that mapping one time. The RETS server itself actually maps their local data to the schema saving you time and money.

I guess FTP is much older though, it's basic current form was defined in 1980 and the current standard was written in 1985. RETS is about 10 years old now, so FTP has 20 years of seniority. You could also make a good arguement that in terms of the modern Internet (ie HTTP), they're about the same age.

>As far as the Industry having time to adopt the standard, we, as IDX
>subscribers, in RI, were told of the change 2 weeks ago, and given a month
>to make the change... to me, that is very short notice, requires a rewrite
>of our software, at a cost of some $3500, unbudgeted, in this current
>market...

I would agree that a one month notice is not sufficient. If you haven't looked at the jretsc library, I would suggest taking a look. You can likely build a tool that will query the RETS server and produce the same flat file you are getting now via FTP with a few days of effort, I know I could.

>There are no advantages to it as far as I can tell, and if NAR wants to
>enforce a standard that is really a non-standard, with no advantages
>technologically, then let them pay for the changes we must incur... I see no
>basis to make this change, especially when the connectors are in beta...

You would have to ask NAR about making it a requirement. That was a business decision by the members of NAR, not something the vendor community asked for. Not to say that the vendor community does not support it, most do.

thanks,

Paul Hethmon

Clareity Security

I think the RETS standard is a good idea. I liken it to NDC codes used by the healtcare industry or bar codes used by the FDA which is used for the communication and exchange of data among vendors and providers. As a technology standard it reduces costs for programming, exchanging data, ancillary programs etc.

Standardizations can reduce cost and waste with out sacrificing competitive advantages.

The benefits you point to are really only useful for the vendors of 3rd
party tools. As we are a small firm, and only require IDX data, the rest is
simply useless to us.
 

I am familiar with FTP, and have been using it since its inception. As the
field definitions do not change much over time, the queries you speak of
are, again, only useful to third party vendors. For us, they are again
meaningless.
 

Just because a software package has been used for years does not mean that
it is not still in beta... virtually all the RETS Connectors are still in
Beta. To me, relying on beta level development for mission critical purposes
is just a very dumb idea. As RETS stands for Real Estate Transaction
Service, the "standard" is restricted to real estate industry folks, whether
vendors or otherwise. As such, I find that development will either suffer,
or be extremely costly, as with other real estate specific standards. To me,
relying on this is a bad idea at best.
 

But even if the technology is under supported, unproven, and provides no
useful advantage to end users, and only really to MLS and 3rd party vendors,
the nature of the roll out, the discontinuation of FTP, short notice, and
expense make this change, to me, an extremely costly bad idea, and of
course, we have no choice, as usual, with NAR decisions.
 

Immature software without development time is just dumb, and I am sure that
in most industries, this would be laughed out of existence in a matter of
minutes.
 

Paul.
 

Paul,
Good comments, let me respond to some specific points you make.
>My own software company built our websites. We see no need to move from a
>truly open standard of FTP to a so called standard that is particular to
the
>real estate industry, and which provides no benefit over standard FTP.
Being
>a standard for a century would not mean that RETS Connectors are not in
>BETA... please find me a RETS connector that runs on Linux servers that is
>not in BETA...? I find none... even Windows server RETS connectors are in
I use the jretsc library myself. Written in Java, it runs on any JVM
including on my Linux boxes I run. I've been using it for several years now
including with the Statewide RETS server.
>Beta, as far as I can see... this is because despite being a standard for
>years, no one has actually developed tools for this that are beyond Beta
>stages of development. With good reason: there are no technological
>advantages to it. I own a software company, and have had my developers go
>through this... none can see a point to it... most call it ludicrous. FTP
>has been proven, is not restricted to one industry, and is far less costly.
FTP is File Transfer Protocol, no secret there. I started using it in 1991,
even helped update the RFC's in the late 90's. >From a technology point of
view, FTP is dead simple. Move a file from point A to point B. The only
thing it cares about as far as the file is concerned is whether its text
format or binary format. Text format means it should translate the end of
line character from the host file system to the network standard. It does
have its problems though, its insecure in that it transmit login credentials
in clear text. You can get around that by using one of the secure variants,
but those are not as available. It also has the problem of the server making
the data connection back to the client by default. Passive mode helps with
that.
>From the point of view of a former MLS software vendor (I was with
Marketlinx early on), we had a hard time managing FTP on a Windows based
server. It didn't integrate well into the rest of the systems and it took a
seemingly tremendous amount of staff time to maintain the multiple file
formats that everyone wanted. Pictures themselves were pure horror.
RETS is a data transmission standard. It defines a protocol, and most
importantly metadata that allows software to figure out what data is
available and what type that data is. It was developed as a machine to
machine protocol, not human to human. With RETS, i can query the metadata
and find out there are 97 fields in the Residential data. I can find out
what each of those fields is. I also like the fact that as a consumer of
RETS data, I am in control on when I get those updates. I have a lot of RETS
feeds where I make queries every 5 minutes to update my data. But I don't
have to get the multi-megabyte file since I only ask for the data that
changed in the last 10 minutes each time. Once I get that data, it's already
formatted for me to consume. I dynamically grab the fields I want (and only
those fields) and feed those directly into my systems.
 

>Sounds to me that the third party companies like this, and NAR likes this,
>but there is no benefit to subscribers, at least as far as we can see.
I would say that the reasons above are why vendors like it. Vendors are out
there to provide a service to the real estate market. If they can do it in
an efficient manner, then they win and their customers win. RETS was
developed to allow vendors to have a common standard to exchange data. So
you don't have a different way to obtain data on every MLS system you need
it from.
 

>Please also advise me as to what technological benefits there are to a RETS
>technology over FTP, which is much older, proven, and less expensive?
Beyond what I've already mentioned, it has a great benefit the first time
you go to get data from more than one RETS server. The only thing that
changes is that in MLS A, the price field is ListPrice while in MLS B, the
price field is LP. You map the source system names to the fields you need
for your system. You might also look at the syndication schema standard.
That was developed by RESO in conjunction with Google, Trulia, Zillow and a
few others. It defines a standard data schema with around 50 of the most
common data points. If you can get that schema, you do that mapping one
time. The RETS server itself actually maps their local data to the schema
saving you time and money.
I guess FTP is much older though, it's basic current form was defined in
1980 and the current standard was written in 1985. RETS is about 10 years
old now, so FTP has 20 years of seniority. You could also make a good
argument that in terms of the modern Internet (ie HTTP), they're about the
same age.
 

>As far as the Industry having time to adopt the standard, we, as IDX
>subscribers, in RI, were told of the change 2 weeks ago, and given a month
>to make the change... to me, that is very short notice, requires a rewrite
>of our software, at a cost of some $3500, unbudgeted, in this current
>market...
I would agree that a one month notice is not sufficient. If you haven't
looked at the jretsc library, I would suggest taking a look. You can likely
build a tool that will query the RETS server and produce the same flat file
you are getting now via FTP with a few days of effort, I know I could.
 

>There are no advantages to it as far as I can tell, and if NAR wants to
>enforce a standard that is really a non-standard, with no advantages
>technologically, then let them pay for the changes we must incur... I see
no
>basis to make this change, especially when the connectors are in beta...
 

You would have to ask NAR about making it a requirement. That was a business
decision by the members of NAR, not something the vendor community asked
for. Not to say that the vendor community does not support it, most do.
thanks,
Paul Hethmon
Clareity Security
 

Have a great day!
 

Best regards,
 

Paul Silver
Executive Vice President
Focus Professionals, Inc.
Direct Tel: (401) 293-0131
E-Fax: (401) 633-6938
 

http://www.TheFocusRealEstateGroup.com
http://www.HomeSalesRI.com
http://www.Homes-In-MA.com
http://www.WaterfrontFinance.com
http://www.WeBuyNERealEstate.com
 

Real Estate Resources
 

Blogs:
http://Blog.HomeSalesRI.com
http://www.AboutBuyingRealEstate.com
 

Resources:
http://Buyers.HomeSalesRI.com
http://Sellers.HomeSalesRI.com
http://Mortgages.HomeSalesRI.com
http://Listings.HomeSalesRI.com
http://FindHouses.HomeSalesRI.com
http://Rentals.HomeSalesRI.com
 

This message is the property of Focus Professionals, Inc. or its affiliates.
It may be legally privileged and/or confidential and is intended only for
the use of the addressee(s). No addressee should forward, print, copy, or
otherwise reproduce this message in any manner that would allow it to be
viewed by any individual not originally listed as a recipient. If the reader
of this message is not the intended recipient, you are hereby notified that
any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is strictly
prohibited. If you have received this communication in error, please
immediately notify the sender and delete this message.

After much research, we find that ALL RETS connectors are in BETA. ALL...

The change, suitable for third party IDX solutions, and for third party
users of the data, like Point 2 or Move, Inc., may be fine... but for end
user subscribers, there is virtually no benefit.

The cost of implementation for our firm is now approaching $10K... short
notice, no useful benefits, and extreme cost in this market place make the
change ludicrous at best. At least for end user subscribers with custom
software...

As I said previously, just because a standard has been around for a while
does not mean it is not in BETA... Beta technology does not refer to
standards of implementation... it refers to products that implement the
standards, and these are ALL in beta... must not have been much demand for
it until recently.

I consider the NAR committee extremely biased in this instance, wholly in
favor of third party solution providers, like your firm, or MarketLinx...
for us, there is no benefit, high cost of implementation, and short
deadlines.

In this marketplace the timing is ludicrous, the technology is too.

A waste of time and money in my view, that does not help actual agents at
all.

But politics being what they are, I am not surprised that NAR is doing
this... after all, agents have frequently lost out in favor of third
parties...

Paul Silver

Paul,
I had to stop and comment a bit on your feelings about RETS. To say that
"RETS Connectors" are in beta stage is not accurate. The RETS standard has
been around and in use for the last decade. It moves a tremendous amount of
data on a daily basis in our industry. When the MLS Technology committee
made its recommendation to require that all REALTOR MLS organizations
provide RETS, the percentage of MLS' already offering RETS was 80% or
greater. Since that time, that percentage has grown. At the recommendation
of RESO (the Real Estate Standards Organization, in charge of the RETS
standard), the MLS Technology committee pushed back the required date from
June 2009 to December 2009 to allow those systems not quite ready, to get
ready. So, our industry has had something like 18 months to accommodate this
change. I also want to point out that the requirement to provide RETS does
not mean that an organization cannot provide FTP. Whether any particular MLS
provides FTP is a business decision they must make.
Remember that RETS is an open standard, just like FTP. Just like FTP, there
are many different programs out there that implement the protocol, some
better than others, some designed to provide one way to access the data and
some a different way. Many of those programs and toolkits are designed to
replace FTP as a transport mechanism. So that your website vendor can make a
RETS query and end up with a familiar looking flat file. Of course, that
only begins to scratch the surface of what RETS can do.
I don't want to comment too much on your particular system, but the MLS
technology provider for Statewide MLS, Marketlinx, has been involved in the
RETS standard since the beginning and is a leader in the field.
I should also say that I do sit on the RESO board, though my statements here
should not be taken as "official" statements of RESO.
thanks,
Paul Hethmon
Clareity Security

Have a great day!

Best regards,

Paul Silver
Focus Professionals, Inc.

What is RETS?
I am new to this community and the acronyms are out of my league

Thank you

Kay Basden, Realtor
Direct: 757-286-2181
Office: 757-587-2800
Judy Boone Realty, Inc.
809 E Ocean View Ave
Norfolk, VA 23503

Editor's Note
Hi Kay,RET stands for Real Estate Transaction Standard. More info on RETS is available at:http://www.rets.org/Saul