[Rets-dev] On Reference Implementations

Fri Mar 16 15:35:29 CDT 2007

The points that have been raised are all valid points, but I feel that
targeting the RETS Standard as being too complex is really not fair and not
accurate. The RETS standard is not too complex, it is as complex as it is
required to be to solve the problem it was asked to solve.  Moving to Web
Services was hoped to be a better solution that would allow a still simpler
interface to be built and, as such, open it up to more developers.  I point
out, however, that RETS was targeted to developers, not end users.

Up to now the RETS community has been focused on building the standard that
allows disparate data to be shared out from a RETS server in standardized
manner controlled by the MLS systems and that is more secure than using a
simple FTP feed. I believe we can all agree on the fact that this has, in
fact, been achieved.  All the major MLS vendors provide RETS servers and
there are many clients out there that use RETS to get all the data that they
need. There are, of course, some compatibility issues but I do feel that
these are getting ironed out.

Where we appear to be lacking is in providing good front end tools that use
the standard to extract data from any RETS server. We need to provide the
'ATM' that allows the data to be retrieved painlessly for a wider audience.

What we also apparently lack is the ability to properly communicate what the
tools that we have provided for the community can really do.

For instance, if you download the latest version of Conduit, you will find
that it fully supports being run on any back end server that runs java. It
can be started up as a service on any Windows server and can be started up
as a background task on any other kind of server that runs a JVM (which is
all of them as far as I know).  Conduit is just such a tool and was
developed exactly to fill-in the gap that you rightly point out is there.
Now, it does lack the ability to get images, which will quite likely be in
the next release by the way.  In case you are interested, the reason for
this is that it was originally developed just for the use of MRIS customers
and they have a resource called PROP_MEDIA that provides all the URL's
which, at the time, was deemed much simpler to manage for end-customers than
using the GetObject transaction. We need to update Conduit to use GetObject
to give it the last piece of functionality that it needs to become the 'ATM'
of RETS.

Perhaps we also need to get more developers tasked with writing other tools
that are similarly easy to use that run in Perl, PHP or ASP and all of these
tools should handle images as well. I would suggest that this is something
that NAR could spearhead.

Perhaps we also need to consider focusing on developing the end-user tools
to make the standard more accessible to everyone before we focus on RETS
2.0. I say this because it is clear that although RETS 2.0 will lower the
entry bar for developers, it really does not address, in any way, the issues
raised on all the threads that I have read over the past few days. And, once
we develop RETS 2.0, we will need the clients to keep pace and make the new
standard still easily accessible by end users.

Regards,

Sergio Del Rio

Templates 4 Business Inc.

  _____  

From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Mike Reilly
Sent: March 16, 2007 12:01 PM
To: rets-dev at rets.org
Subject: RE: [Rets-dev] On Reference Implementations

I agree with Frank here.  I work for a brokerage of 1.  I'm currently
working on a few websites for the broker that display information grabbed
from a RETS server.  Because of the nature of some of the queries, I simply
want to pull the RETS data into a local relational database - exactly what
Frank mentions (wanting RETS to do what an FTP feed does).  From there I can
create my own indexes, run some of my complex queries (some are "IN"
statements that search the 2 largest fields, remarks and supplement, and are
unfeasable to run across thousands of active listings in a "live search" -
so I run the query on my end and update a database field to indicate whether
it matches my IN query, then run the live search against the new indicator
field).  I say all that just to show why I need a local copy of data, and
not just the live RETS feed. I don't want the FTP feed, because the dataset
is limited.  RETS offers all the fields available to us as a broker, so
that's the method in which I need to pull the data.

All I want is a ready-to-use PHP/ASP script that I can schedule on a remote
server to replicate the RETS data into a mySQL database.  The easiest
programs I've seen are ezRETS and MRIS Conduit, but both are not programs I
can put on a remote server.  I got close with vielerets, but the
documentation is limited when it comes to the database setup side and I
haven't figured out how to get the picture data.

So right now I'm using MRIS Conduit scheduler to create XML files, parsing
the XML files locally, and sending the updates to the remote database.  But
what if I don't have my laptop on, etc etc?  I need a hands-off updating
system that can run on a remote server.

While I realize that the RETS community isn't responsible for developing
client apps, an easy-to-implement data replication solution using the RETS
framework would go a long way to build support for RETS.  Maybe there's an
easy solution that's out there, but I haven't seen one yet.  Even though
I've done plenty of coding, implementing RETS has quite a learning curve.  I
don't have any problem seeing the value of RETS, I only have a problem with
easily implementing it.

Just another tech guy trying to figure this out,
Mike Reilly

-----Original Message-----
From: rets-dev-bounces at rets.org [ <mailto:rets-dev-bounces at rets.org>
mailto:rets-dev-bounces at rets.org] On Behalf Of Frank Wanicka
Sent: Friday, March 16, 2007 9:51 AM
To: 'Sergio Del Rio'
Cc: rets-dev at rets.org
Subject: RE: [Rets-dev] On Reference Implementations

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>
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/> 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.
>

_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
 <http://lists.rets.org/mailman/listinfo/rets-dev>
http://lists.rets.org/mailman/listinfo/rets-dev 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070316/b9582b00/attachment.html