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

Fri Mar 16 09:36:04 CDT 2007

Glad to hear it thought we were getting close to the realisation of Godwin's Law [http://en.wikipedia.org/wiki/Godwin's_law].
  ----- Original Message ----- 
  From: Stuart Schuessler 
  To: 'Marc G. Smith' ; Rets-dev at rets.org 
  Sent: Friday, March 16, 2007 3:13 PM
  Subject: RE: Direct Response to Re: [Rets-dev] Google Base Housing vs. RETS

  Sorry about that.  My font messed up.  At least it is not in all upper case.

------------------------------------------------------------------------------

  From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf Of Marc G. Smith
  Sent: Friday, March 16, 2007 8:37 AM
  To: Rets-dev at rets.org
  Subject: Re: Direct Response to Re: [Rets-dev] Google Base Housing vs. RETS

  No need to shout :)

    ----- Original Message ----- 

    From: Stuart Schuessler 

    To: dsrockets at gmail.com ; Rets-dev at rets.org 

    Sent: Friday, March 16, 2007 1:31 PM

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

>>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 server4.   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 login2.   Examine the Metadata3.   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.

----------------------------------------------------------------------------

    _______________________________________________
    Rets-dev mailing list
    Rets-dev at rets.org
    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/ff4e256c/attachment.html