[Rets-dev] On Reference Implementations

[Frank Wanicka]

That would definitely be a good start. Also, having a one or more turn-key
client solutions would help. Developer tools/APIs are great, but having a
simple, fully-finished client app would really help the people out there
looking to get at the data feed they have access to, that don't want to
write their own client application, or don't have the skill to do so. If
there are already full client apps available, they should definitely be more
publicized. The RETS.org site has a Clients page, but it's not clear even to
me (much less a newbie) what is what there, and when I click the links for
what I would assume would be free clients (the RETS Ref Impl Client and the
VB RETS API), I get a 404 error. If I click on the main Products link,
there's one link to a company that does custom websites.

I know a big stumbling block with RETS has been getting the agents/brokers
to understand the value of it. When you make it difficult for the ones who
do try to implement it, that's not helping the cause. Yes, there are many
people using RETS on a daily basis, as the RETS community keeps pointing
out, but if you took a customer satisfaction survey of client-side users, I
doubt you'd be happy with the results. I doubt anyone thinks it's the best
thing since sliced bread. Most are using it because that is what is
available to them.

We have RETS and FTP feeds available for the boards we service. The only
entities using the RETS feeds are Realtor.com and other big players. Every
one of the brokers we provide a feed to uses FTP. If they could come to
RETS.org, download an app that could grab the data and photos and output it
to CSV, a database, or whatever, they might see a lot more value in RETS.
Instead, they are told to download a DLL and create their own client app.
After their eyes glaze over, they decide to stick with the FTP feed. I think
there are a lot more people out there than this group estimates that just
wants RETS to duplicate what an FTP feed does. They just want to get the
data and photos, and then they'll manipulate it as they see fit.

Maybe the RETS community thinks the server-side is where their focus should
be, and the client side should be left up to third parties to develop, but I
think you're missing the boat with that mentality. This is a client-server
standard and no matter how good one side is implemented, if the other is
lacking, you've got a problem.

I'm way over my 2 cents now.

_________________
Frank Wanicka
Real Estate Technologies, Inc. 


> -----Original Message-----
> From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of
> Sergio Del Rio
> Sent: Friday, March 16, 2007 12:10 PM
> To: 'Steve Verba'; 'Matt Lavallee'
> Cc: rets-dev at rets.org
> Subject: RE: [Rets-dev] On Reference Implementations
> 
> And I will also mention that there is a comprehensive suite of Java based
> tools (that have also been proven to be easily wrapped into .NET classes)
> that are freely available at:
> 
> http://openrets.mris.com/
> 
> Using the JRETSC interface, it takes less than a page of code to connect
to
> ANY RETS server, issue the query, retrieve the data and pull the images
> whether the server provides simple URL's or images with the GetObject
call.
> 
> I built the JRETSC interface primarily to help my developers be more
> productive and not have to learn the in's and out's of RETS protocols, but
> we published it as open source on SourceForge to help all of the community
> more easily adopt RETS.
> 
> I think this interface shows how truly easy it can be to build any RETS
> client that is also metadata aware.
> 
> So, you see, there are tools out there, perhaps we need a better set of
> links on the RETS website to point to all the tools that are available.
> 
> Regards,
> Sergio Del Rio
> Templates 4 Business Inc.
>