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

[dsrockets at gmail.com]

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/20070315/22230a98/attachment.html