[Rets-dev] On Reference Implementations

[Mike Reilly]

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/aa39805f/attachment.html