Direct Response to Re: [Rets-dev] Google Base Housing vs. RETS

Fri Mar 16 08:31:17 CDT 2007

>>High adoption rate?  How many times does a post come through here and the
MLS doesn't even support it?  
>>And I think I am offering ways to make it less complicated. 

Yes, high adoption rate.  Every major MLS vendor in the country uses RETS.
I would dare say that over half of the real estate agents in the country use
it and don't even know it.  There is a very large industry structure built
around RETS.  If an MLS is not using RETS at this point then they are
putting their members at a competitive disadvantage.

Were you realistically expecting everyone to drop the RETS standard and
start using GoogleBase? We had it simpler using FTP feeds.

This is an "I can't get the data" argument gone awry.  If you are not
technically capable or too lazy to put forth the effort to get the data that
is really not anyone's problem but your own.  As I said before ask a
question about your problem and someone will be glad to help.  Proposing
that everyone switch to your way of doing things because you do not want to
learn something new is just silly.

>>Look at the dang usage, Napoleon.  It is 90%+ just pulling listing data.

Yes, look at the usage.  Pulling listing data with business rules applied to
appropriate fields such as expiration dates, MLS Logging of where the data
is going, Client Vendors with agreement with MLS Vendors and MLS Boards
about access to data.

>>Why stray to something that does everything and a whole lot more, for such
a small usage?  

It does a whole lot more if you want to just give away the data.  It is like
having a retail shop and someone coming in and telling you that you could
get rid of your stuff a lot faster if you put it out on the street for free.
It is not even a sane idea.

>>If you don't think that such a high usage is solely pulling the data for
repurposing (or how you defined it as a classified ad), 
>>then please show me some examples.

Prospecting, Hot sheets, media management, statistical reports, etc.  I am
sure I could come up with more.  There are just a massive number of uses for
RETS.  Let's say you have a change you would like to make to the structure
of the GoogleBase feed.  You think Google is going to make it for you?  HA!
That's Funny!  With RETS and especially RETS 2.0 you can define your own.

>>so one would be able to cURL or wget the rets data and not worry about any
other intricies with both

>>rets1

Yes, and I have personally used wget to get RETS data.  What is the
problem?:

1.      www.someserver.com/rets/login (Obtained from the MLS Board or
Vendor)
2.  Look at the response.  It gives the path to the metadata and the search 
3.  using the metadata link from the login download the metadata and examine
it.  It is the documentation for that RETS server
4.  using the search link from the login do your searches.  Once you know
the metadata resource, class and fields you are looking for you can do the
wget over and over and probably cURL although I have not used it.

How would you do it with Googlebase?
1.      Obtain a login
2.  Examine the Metadata
3.  Perform the search.

>> so ssl and username/password pairs are not strict enough?  How much more
security do you need? 

More than Googlebase is offering.

  _____  

From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of dsrockets at gmail.com
Sent: Friday, March 16, 2007 1:12 AM
To: Rets-dev at rets.org
Subject: Re: Direct Response to Re: [Rets-dev] Google Base Housing vs. RETS

Thank you everyone for your response, I will try to do the same

On 3/15/07, Paul Stusiak <pstusiak at falcontechnologies.com> wrote: 

While others have done a good job of responding to this thread, there
are some questions I have.

It would be helpful if you could expand on some of your comments to help
me understand better.

dsrockets at gmail.com wrote:
>
> So why is RETS so complicated again?  No one explined the theory 
> beihind it, when the same things are accomplishable, as secure, with
> much simpler technology (see googlebase)?
>
Please explain. Why do you think it is complicated? And what do you mean
by again? (over parsing I know...) 

complicated: rets gets data, does it not? I see many emails about getting a
client up and running, barriers to entry for programmers.  The level of
technical skill neeeded to get rets going far outweighs the level for other
data transfer applications that I have ever used, and I was only leveraging
the google data transfer topic, as that was the one that got started here
(not by me originally) 

again: referring to when this thread got sidetrackered pre holiday.

dbt wrote:

  Google base is not "simpler technology".  You're simply only seeing the
  client interface.  The kind of technology used to do their searches,
  storage, indexing, and typed properties simply isn't exposed to
  you, unlike in RETS, where that stuff is not only exposed, it must
  be standardized to support multiple clients.

  Don't confuse a protocol with a product.

yes, but how a RETS server retrieves the data SHOULD NOT matter.  What
matters is how it provides it back to the client, and in that case they are
exactly the same.  the way I see it it abstracts the mls data servers
technology (what you mention above).  Maybe the concept (if this even exists
in RETS, im unlcear) of a transparent server->mls server is ridiculous, and
should that should be specific for each mls's server.  It should not be a
feat for the standard. 

And unfortunately, google base supports many more clients that RETS, as most
people probably coded their own connection scripts.  Granted, it is a half
dozen lines of code, but that is the case in point:

give me some data google = easy

give me some data rets = not as easy

and unfortunately, the usage for the data is practically the same (see usage
discussion below).  So in essence, two paths, one goes the long way, one
goes the easy way.  Both get to the same destination.  Am I missing
something?  

JP Fielding worte:

  i think hes saying that gbase has a smaller barrier to entry than rets
from
  a client perspective.   as a rets client user, i have to agree.
Exactly......and it goes back to IF RETS does define the server, that is
just bad form.  It should only define how a client talks to a rets server,
not how a rets server talks to what ever is on the other side of the
transaction, once again, if that is what is being debated here. I kind of
lost track at this point!
dbt write:
  Sure, but again, this it's easy to code against a single application.
  Don't confuse that with an interoperable standard, which is the best
  you're going to get unless there's a centralized provider of this 
  kind of data -- and a search API.

it should be just an API, in some ways. what ever RETS server I hit, I know
1) how to connect 2) how to auth 3) how to query 4) that Ill get some data
dump.

the issue of RETS magically (or through the use of tech) to just know what
it is getting will eventually need to be manually looked at anyway if
datasets are allowed to grow from the core defined payload.  I sure know my
code wont be able to (or better yet, I wouldnt want it to) just make
tables/fields based on some returned data descriptions.

if a core dataset is defined, I can easily map that into an app.  If I care
to use the additional fields, I will have no issue looking at those 900+ or
whatever I am connecting to so that I understand what they are providing me.

In general, I just want rets to be the connector and the puller.  Ill do the
rest.

Stuart wrote:

  It's no more complicated than any other standard.  Given the high adoption
  rate apparently there are others that do not think it is too complicated
  either.  Any ideas to make it less complicated are always welcome.  

High adoption rate?  How many times does a post come through here and the
MLS doesnt even support it?  And I think I am offereing ways to make it less
complicated.  

Look at the dang usage, Napoleon.  It is 90%+ just pulling listing data.
Why stray to something that does everything and a whole lot more, for such a
small usage?  If you dont think that such a high usage is solely pulling the
data for repurposing (or how you defined it as a classified ad), then please
show me some examples.

Stuart wrote:
  It is an FTP push.  There is no
  identity management, no control over who gets the data, no business rules
  that allow owners of a listing to see field like expiration date, etc.
It
  is a classified ad.

adding to my last point, by the time this is used by 90%+ of the end users,
it is exactly that, a classified ad, with little or no acess control.  

Maybe == here is a thought == the standard needs to be separated for use
cases.  Simple listing retrieval, priviledged listing retrieval, and
transactions (all of course having authentication mechanisms, I am not
implying simple to mean open).  Make workgroups of those that need to
implement for each level.  I'll tell you what, the simple listing retrieval
will be the one with high adoption rate, and longevity.  

What theory are you talking about? Is it the decisions that were made to
select particular technologies? Is it the real estate context? 

why not keep it simple?  why encapsulate everything and the kitchen sink
when defining  'possible' data that can be transported?

   transport level solution like TLS. That is not sufficiently secure to do

so ssl and username/password pairs are not strict enough?  How much more
security do you need?  Or is it simply because you can do this uber level
which showers kudos from the business side but hatred from those that really
understand it added neglible security? 

> The need for the concept of a client is crazy.  It should just be
> easily defined in most programming frameworks, and just 'readable' in
> a pure http browser (pure XML with https url based auth -) 
>
  I really don't follow you here. As another posted replied, you can do
  this within RETS1 today if the various parties agree.............. RETS2
on the
  other hand, does allow the base stubs to be easily defined in most 
  mainstream frameworks. 

so one would be able to cURL or wget the rets data and not worry about any
other intricies with both

rets1 and 2?

Im just saying the concept of being able to walk the data blindly and just
know what to do is the holy grail.  At some point your code needs the logic
for what to do, especially if one server can tag on extra data above and
beyond the defined payload. 

having one STANDARD way to access the MLS system makes sense.  Forcing all
data to conform is where everyone is hitting roadblocks, and it has been
discussed on this thread multiple times.

Stuart wrote:

  The core RETS specification does not require a special client.  Everything
  can be done through the browser.  In fact originally it was set up to work
  nicely with just some simple javascript if you wanted to put a user
friendly
  search screen on top of it.

So, take that concept and move away from it with RETS2?  Doesnt make sense
here.  Have there been any javascript implementations out there?  I just
dont see that viable (not that I wouldnt think that would show true
versatility) with the current ways of doing.  Thats not to even ask how
would one get the data cross site?
 In fact, is most of the core of RETS2 still not php/python friendly?

> Yes, that is going to be fun seeing that most of the client apps out

> there are php based.

>

!? Are you asking if PHP supports web services? Paula O'Brien already

pointed out a package and a very unfocused Google search of ["php web

services"] returns almost 28,000 pages. I'm assuming that we'll find

that there are some fun inconsistencies to start that will get ironed

out as development progresses.

most of those are probably about how poos soap support is, although it is
coming along.

here are two links on some soap support issues:

http://solutions.amazonwebservices.com/connect/message.jspa?messageID=43461

http://docs.codehaus.org/display/XFIRE/PHP+Interoperation

   Do you have some facts to support the assertion that most of the client
   apps are php? 

I believe at least one of the CRTS is, and it have been rolled into various
other projects.  I would say it has the widest traction, as you pointed out
many vendors are using PHP.  If many vendors are using PHP would you not
think they are the high use cases, and therefore the high technology doing
the connecting.  I could be comeplety wrong...my logic sometimes seems too
basic for it to make sense.  Hey maybe all those PHP vendors comprising
almost all the rets usage are using .NET ? 

lets try it your way: google

rets php: 248,000+

rets java: 52,000+

rets asp: 177,000+

granted rets could mean a lot more than in our little world, but this is
assuming all its variations would be a 1:1 

> I feel like I am part of the 300!
>
Would that be a Chrysler 300?

No Spartan ....

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

--
Paul
Falcon Technologies Corp.

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