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

Stuart Schuessler sschuessler at tds.net
Fri Mar 16 13:36:58 CDT 2007


>>this is almost ridiculous now

I agree

The answer is for you to get involved with RETS2 and post a proposal around
the GoogleBase layout.


Stuart

-----Original Message-----
From: dsrockets at gmail.com [mailto:dsrockets at gmail.com] 
Sent: Friday, March 16, 2007 10:49 AM
To: Stuart Schuessler
Cc: Rets-dev at rets.org
Subject: Re: Direct Response to Re: [Rets-dev] Google Base Housing vs. RETS

this is almost ridiculous now, as you completely have made you
defensive stance that of a concept of googlebase, where as I never
wanted to use googlebase to store nor access the data in question, but
rather comparing transport mechanisms.

but of course, you need to be defensive and sway the topic.  But I
digress, see below

On 3/16/07, Stuart Schuessler <sschuessler at tds.net> wrote:
> >>I can use an ATM, as well as most people.  Thats the vessel for
> >>communication.  I dont need to know how it communicates and-or   what
> >>standard it uses.
>
> When you use that ATM you are using a client application that speaks to a
> server following a standard.  You as the end user do not know you are
using
> a standard.  I am sure during the development of the ATM standard someone

you seem to always validate my point in your round about way without
even realizing it.  Frustration and anger can do that to a person, as
I said everything you repeats


> wanted to put it all on GoogleBase, but that would be crazy right?  I am
> sure that some thought the standard was too complicated.

only child huh?  open your eyes and move off your hangup here


>
> So now you are saying you do not want it on Googlebase.  Ok.  You want the
> Googlebase metadata- right?

NO.  again, was comparing ease of implementation to same end result


>
> There is nothing in RETS that would prevent a simpler data feed.  You are
> not even required to have a login.  You could just have a search.  It is
the
> implementation of RETS to serve different business needs that complicates
> it.


and you would hear the natives go balisitc becuase that is a
misinterpretation and/or it 'too easy'.  IMagine that.  What happened
to the LiteRETS standard?  I think it was shot down becuase it was

- actually answering the REAL need
- in a simpler less obtrusive approach.


WOW, maybe cause it would have made people lives easier and :some:
wouldnt be able to throw your huge IT package around? and keep
control.  I am sorry to others on the list that have to deal with me
needing to notch this up.  I thought I was being too clear, but others
on the list still werent listening


>
> >>you completely missed the point of every email thus far from me.
>
> No, I think I completely understand your point.  Yes I do think that if
you
> had your choice all real estate data would be in GoogleBase.

you (above) realized this was not my intent, and now you are back on
it.  I realize you probably wont reply to this email, or now will you
have to cause I called you on it? or now that I called you on it and
made it known that you have to, does that open you up to not having to
respond?  Of course response is up to you (_*_)


 I think that
> there is a lack of understanding about what happens in real estate

that makes me laugh.  as you support then contradict points.
unfrotunately RETS has a GRAND SCHEME, but its real use is just a
small subset of that.  My point (and other have voiced it) is simply
why make a all encompassing standard, when people only need 1% of it?

case in point 1.x does 99% of 90% of the usage, yet :someone: thinks
RETS needs to do more?  come on!  Make work for yourself in other
ways, please?


>
> >>the client and the standard SHOULD NOT define business rules.  What
> >>open industry standard defines business rules?
>
> I agree and RETS does not.  It provides a way to support the business
rules
> that are defined.  It even provides a way to publish some of those rules
> back to the client.

point taken, but your previous email made it sound like RETS should
define rules, such as who gets access, logging usage, etc....it
SHOULDNT

>
> >> What is this Mismo
>
> You are actually working in Real Estate - right?  MISMO is the mortgage
> industry standard.  Paul had an earlier email about that


I was being facetious as to WHY it needs to be talked about within
this realm of a standard, not in terms of its own definition.


I'd like RETS to do my laundry and be an EBAY sniper for me, can we
add that in there as well?  Ill write the proposal and pass it along

.
>
> >>my friend, you have just defined everything you do AFTER THE FACT of
>
> >>RETS when the data has been repurposed onto a different system.  Is
>
> >>RETS now supposed to be a complete tool to provide every view of the
>
> >>data sliced and diced that you want?  Or is it supposed to communicate
>
> >>with an abstracted SERVER to get the data.  Oh and we are still only
>
> >>talking about listing data!
>
> Uh - wrong.  I am defining concerns that a server provider has before the
> data is even obtained.  The business rules and fields need to be in place
to
> support various "repuposing".  Yes RETS can provide different views of
data.

it should nt be up to RETS to define the views, it should be up to the
server provider to define what he hands off the the RETS client in a
'standardized' manner.  The client should just ask for X Y or Z


> A client is suppose to communicate with a server to get the data and based
> on a number of factors that are defined by the MLS the view of data the
> client gets may be different and support the use of the data that follows
> the client's purpose for existing.  There is really nothing abstract about
> it.

that I think is where form verse funtion is failing within RETS.  You
are trying to form something that is not going to meet the true
function


>
> >> with RETS2 ?
>
> I have not used wget on RETS2.  RETS2 does follow the HTTP protocol so
there
> is not reason it cannot be done.  SOAP is just a standard on HTTP
(probably
> be better on Googlebase) so if you would like to got to the trouble of
> making the API calls using wget then I am sure you could do that.  You do
> know that the tools that generate everything for you in SOAP are just
tools
> right?  They make the same HTTP calls.
>
> Stuart
>
>
>
> -----Original Message-----
> From: dsrockets at gmail.com [mailto:dsrockets at gmail.com]
> Sent: Friday, March 16, 2007 9:20 AM
> To: Stuart Schuessler
> Cc: Rets-dev at rets.org
> Subject: Re: Direct Response to Re: [Rets-dev] Google Base Housing vs.
RETS
>
> below:
>
> On 3/16/07, Stuart Schuessler <sschuessler at tds.net> wrote:
> >
> >
> > >>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.
> >
>
>
> this supports my point.  Its a listing data transfer standard.
> Where is the adoption in the appraisal industry? the mortgage industry?
>
> > Were you realistically expecting everyone to drop the RETS standard and
> start using GoogleBase? We had it simpler using FTP feeds.
> >
>
> you completely missed the point of every email thus far from me.  I
> dont want to use googlebase.  I was merely comparing that two things,
> same end result - one easy and one not
>
>
> > 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.
> >
>
>
> its interesting that there are so many on both sides of this argument
> and the fact that this is intended for Real Estate and should be
> simple for those directly in real estate and not have to employee
> outsourced third parties (which I am suspecting each of you are that
> have answered these emails) is just not right.  It should not be
> technically restrictive to need outsourcing.
>
> I can use an ATM, as well as most people.  Thats the vessel for
> communication.  I dont need to know how it communicates and-or   what
> standard it uses.
>
>
> > >>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.
> >
>
>
> again, you are just supporting my stance of this is all about the
> listing data.  What is this Mismo, and other support.
>
> the client and the standard SHOULD NOT define business rules.  What
> open industry standard defines business rules?
>
> MLS logging , handled by the server not the standard
> appropriate field returns, handled by the server not the standard
>
> again, it seems like everyone is trying to cram every piece of data
> management into this.  Business rules are not that transparent or over
> layable.
>
> > >>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.
> >
>
>
> missing the point as you did with any discussion around googlebase earlier
>
> > >>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.
>
>
> my friend, you have just defined everything you do AFTER THE FACT of
> RETS when the data has been repurposed onto a different system.  Is
> RETS now supposed to be a complete tool to provide every view of the
> data sliced and diced that you want?  Or is it supposed to communicate
> with an abstracted SERVER to get the data.  Oh and we are still only
> talking about listing data!  If you notice
>
>
> >
> >
> >
> >
> > >>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?:
> >
>
> with RETS2 ?
>
>
> >
> >
> > >> so ssl and username/password pairs are not strict enough?  How much
> more security do you need?
> >
> >
> >
> > More than Googlebase is offering.
>
>
> man, your head is way too far up some other place.  You really think
> this whole thread has been about storing data in Googlebase?
>
> again.  ssl and username/password.  How much more does RETS need?
>
>
> >
> >
> >
>
>



More information about the Rets-dev mailing list