[Rets-dev] Google Base Housing vs. RETS

[JP Fielding]

btw, this (to me at least) isnt an i hate rets thread so much as comparing
some _our_ problems with the ideas of one of the largest collections of phds
on the planet.

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.  i currently
maintain the retsclient java api originally started by cart.  it works
great, but keeping it working transparently across each vendors
interpretation of the RETS spec is sometimes tricky.   not only that, some
things we have to do cant go into the spec.  for instance, one vendor, has
search limits, but doesnt provide for paging.   so the mls (their customer
as well) asked us to implement a custom paging mechanism that basically does
a binary split based on entry dates until we get under their size limits.

a single client server interaction is not tricky, making use of it
transparently across each vendor is.

that said, ive played with the gbase api's, the java based api, the direct
http api, and an htmlunit based client that creates a browser and walks
their sites.   their site itself will be very interesting _when its done_,
but there are still a few features missing and outright bugs.   but in
general, the concept is simple, you submit a _minimal_ dataset.  enough to
present a search result, then a user clicks it and goes directly to the
brokers homepage.

On 3/15/07, dbt <retsdev at develest.com> wrote:
>
> On Thu, Mar 15, 2007 at 06:21:16AM -0600, 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)?
>
> 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.
>
> -dbt
> _______________________________________________
> 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/6f6478d3/attachment.html