[Rets-dev] Google Base Housing vs. RETS

dsrockets at gmail.com dsrockets at gmail.com
Thu Mar 15 07:21:16 CDT 2007


haaaha.  Blast from the past!!! Seems like a good time to dig this back up
as it got a mention on a MLS blog ++
http://www.flexmls.com/blog/?p=23#comment-19

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)?

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 -)

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.

I feel like I am part of the 300!



On 12/21/06, Chadwick Meyer <chadwick at cratemedia.com> wrote:
>
> Here Here. I agree. I've always thought RETS was needlessly complicated in
> it's own obscure fashion.
>
>
>
>
>
> *Chadwick Meyer*
>
> chadwick at cratemedia.com
>
> T. 407/538.9026
>
> F. 866/534.8654
>
>
> *****************
>
> *Crate Media*
>
> 1087 Dees Dr.
>
> Oviedo FL 32765
>
> www.cratemedia.com
>
>
>
>
>
>
>
> On Dec 20, 2006, at 8:56 PM, dsrockets at gmail.com wrote:
>
> been a patient observer in and out of rets for a while, thought I needed
> to put some my own experiences out on this.
>
> I dont think there is any benefit to Google even looking at RETS.  As said
> earlier, they have thier own system and it works just fine.  In fact, RETS
> should look at how Google / Trulia / Oodle handle data (or more closely
> listing) exchange a bit more closely.
>
> All of these are built on simple, yet effective transport mechanisms that
> can handle query based retrieval and updates.  We have implemented both RETS
> for pulling data and all three methods mentioned earlier for update and
> query.  The level of complexity (earlier message) seems to make it apparent
> why Google / Trulia / Oodle have all had large adoption rates.  It gets the
> job done simply and easily.  They are also built using out of the box and
> proven methods.
>
> I'd recommend the powers to be consider these approaches, if not even
> piggyback on them, as they are solid, structured, secure and more
> importantly efficient and straightforward.
>
>
>
>
>
>
>
> From: dbt <retsdev at develest.com >
> > Date: Dec 20, 2006 5:09 PM
> > Subject: Re: [Rets-dev] Google Base Housing vs. RETS
> > To: Eric Madariaga <ericm at nsoftware.com>
> > Cc: David Harris < dharris at fmls.com>, E-mail Rets-Dev <rets-dev at rets.org
> > >
> >
> >
> > There's no reason you can't embed a RETS payload (RETSML or a JSON'ified
> > COMPACT representation) in an Atom document and use an OpenSearch
> > style API to retrieve a set of records with permalinks for each entry
> > that you can use to retrieve/update.
> >
> > GET /rets/search?q=(AREA=+2000) HTTP/1.1
> > Host: rets.example.com
> > Accept: application/atom+xml
> >
> > HTTP/1.1 200 OK
> > Content-Type: application/atom+xml
> > <feed xmlns="http://www.w3.org/2005/Atom">
> > <link rel="self"
> >     href="/rets/search?q=(AREA=+2000)" />
> > <title>Search Results</title>
> > <entry>
> >   <link rel="alternate" type="application/rets+xml"
> >         href="../properties/10029" />
> >   <summary>Server-generated user-readable description, perhaps
> > containing
> >     the address or square feet or whatever</summary>
> > </entry>
> > </feed>
> >
> > GET /rets/properties/10029
> > Host: rets.example.com
> > Accept: application/rets+xml
> >
> > HTTP/1.1 200 OK
> > Content-Type: application/rets+xml
> > ETag: xyzzy
> >
> > <REPropEntry>
> > ....
> >
> >
> >
> > Interestingly, and in completely unrelated news, Google themselves just
> > deprecated their SOAP search API.
> >
> > On Wed, Dec 20, 2006 at 03:28:18PM -0500, Eric Madariaga wrote:
> > >
> > > Not to sound pessimistic, but good luck with that :). Google's format
> > is
> > > based on the GData specs that they have published (basically Atom/RSS
> > 2.0
> > > with extensions).  You would have a MUCH easier time providing a
> > > transformation mechanism for MLS data.
> > >
> > > For example I'd love to see an RSSBus module ( www.rssbus.com) for
> > RETS.
> > > That would  enable you to push MLS data from any RETS capable server
> > > directly to Google base with no additional code.
> > >
> > > -Eric
> > >
> > > -----Original Message-----
> > > From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
> > Behalf
> > > Of David Harris
> > > Sent: Wednesday, December 20, 2006 3:33 PM
> > > To: E-mail Rets-Dev
> > > Subject: [Rets-dev] Google Base Housing vs. RETS
> > >
> > > Just for giggles, I looked at the Google Base Housing API metadata,
> > and of
> > > course, no mention of RETS. Here is the link (I hope):
> > >
> > >
> > http://www.google.com/base/api/itemTypeDocs?verticalName=housing&vertica
> > > lLocale=en_US
> > >
> > > Question is, do we (meaning Paul) open a line of communication with
> > them to
> > > hopefully have them adopt RETS? Something about keep your friends
> > close and
> > > your enemies closer... jk.
> > >
> > > David
> > >
> > > _______________________________________________
> > > Rets-dev mailing list
> > > Rets-dev at rets.org
> > > http://lists.rets.org/mailman/listinfo/rets-dev
> > >
> > >
> > > _______________________________________________
> > > Rets-dev mailing list
> > > Rets-dev at rets.org
> > > http://lists.rets.org/mailman/listinfo/rets-dev
> > >
> >
> > --
> > David Terrell
> > dbt at meat.net
> > ((meatspace)) http://meat.net/
> > _______________________________________________
> > Rets-dev mailing list
> > Rets-dev at rets.org
> > http://lists.rets.org/mailman/listinfo/rets-dev
> >
> ---------- Forwarded message ----------
>
> _______________________________________________
> 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/20070315/e35ca2de/attachment.html


More information about the Rets-dev mailing list