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

[Paul Stusiak]

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:
> 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)?
>
Please explain. Why do you think it is complicated? And what do you mean 
by again? (over parsing I know...)

What theory are you talking about? Is it the decisions that were made to 
select particular technologies? Is it the real estate context?

I'm assuming that you are talking about REST versus WS-*. REST is very 
much simpler than the WS* standards. REST is very similar to the 
technologies used in RETS1. I don't understand your comment about "as 
secure". Security always requires a context to describe it. REST does 
not have any security other than that which may be provided by using a 
transport level solution like TLS. That is not sufficiently secure to do 
anything substantial with the data. RETS2 uses the WS-Security* 
definitions which can be as complicated or simple as you need. Are you 
comparing REST with RETS1? In that case, they have a similar level of 
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. Given that it 
places some additional load on the back-end and that there are lots of 
interesting ways to add value to the data, not a lot of places expose it 
this way if I understand what you are saying correctly. RETS2 on the 
other hand, does allow the base stubs to be easily defined in most 
mainstream frameworks. Given that they are trying to add value, the 
solutions are generally more sophisticated than a raw data dump into a 
browser or even a simple css attached to the response data. I don't 
understand why you need the https url auth. Is this on top of the RFC 
2617 Digest? Most major browsers will support the use of MD5 digest 
directly to the browser, with the noted proviso of supporting the 
non-standard implementation provided by Microsoft.

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

Do you have some facts to support the assertion that most of the client 
apps are php? I would agree that there are a lot of IDX website 
solutions using PHP quite effectively against RETS1 and that they'll 
work fine against RETS2 when the time comes. Are you talking about the 
number of total developers? Certainly it is not by the total number of 
users. If I had to guess, it would be .NET + MFC+ASP (probably missed 
one or more MS technologies here), probably by a wide margin followed by 
Java with PHP and Perl and everything else rounding it out, but that is 
just a guess.
> I feel like I am part of the 300!
>
Would that be a Chrysler 300?

> [snip]
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>   

-- 
Paul
Falcon Technologies Corp.