[Rets-dev] On Variations on Specification Implementations and Balancing required versus optional

[Ryan C Bonham]

Paul,

Sorry, had to chime in here on this.

<quote>
how do I connect to 800 /1300 different systems?" to "how do I connect 
to the 20 or so different system and adapt to their different data 
fields and do I need to care about the remaining non-RETS systems/
</quote>

This is not truly the case in our experience.  There are far more then 
20 implementations of RETS people need to deal with, due to vendors that 
have per MLS setups and do not keep bug fixes, etc updated on all there 
RETS implementation. Again this is not directly the fault of the RETS 
spec, more a vendor implementation problem. It goes back to what I have 
been saying all along, which is that compliance testing is no where near 
strict enough nor are there any consequence to vendors who advertise 
compliant servers, yet in reality are not actually complainant with the 
spec..

On the topic of RETS and complexity, and unrelated to your comment. RETS 
1.x is NOT  hard to implement from a client perspective of communicating 
with a RETS complaint server. It is all the vendor and some spec 
idiosyncrasies that cause the headaches in the real world. From an IDX 
data perspective RETS 1.x works half way decently, although I am the 
first to ponit out some of it's short falls. I infant currently like 
RETS 1.5+ better then I do RETS 2 from and IDX precpective,  however 
this is something I know the community is still working on for RETS 2 
and I am hopefully my opinion of RETS2 for IDX will change. Also true 
not everyone and there cousin can open up a web browser and read data 
from RETS, however that is not in my opinion the goal of RETS, nor 
should it be.



Paul Stusiak wrote:
> The thread Google Base Housing vs. RETS has spanned many different 
> topics, making a single response very difficult. Instead, I will 
> attempt to reply to some individual comments. Please be aware that the 
> context has been narrowed and that may result in the loss of the 
> overarching context. The intent is not to pick on specific people who 
> participated in the thread, but to correct what I see as some 
> misconceptions.
>
>
> jp.fielding wrote
>
> <quote>
> 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. [snip]
> </quote>
>
> Comparing googlebase to RETS is an apples to oranges comparison as 
> others have pointed out. Your observation that getting the standard to 
> work transparently across vendors is true. There are some challenges. 
> I would point out that the situation previous to this was much worse. 
> Vendors previously may have not provided any technique for exposing 
> data or may have used some untimely and frequently broken ftp method. 
> Today, in general, if you can resolve the vendor's different 
> interpretations of RETS, all the same vendor systems will function the 
> same. At the very least we have changed the problem from "how do I 
> connect to 800 /1300 different systems?" to "how do I connect to the 
> 20 or so different system and adapt to their different data fields and 
> do I need to care about the remaining non-RETS systems/" which I would 
> categorize as some progress. As well, we have been able to move 
> some/many from a stale data, once per day if we're lucky and the ftp 
> didn't break to an on-line up to date view of the market. For some 
> applications this is not important. For others, it would be impossible 
> to provide a product that did not have the direct, live access to the 
> system.
>
> I would point out that variations in the implementation of 
> specifications is not exclusively a RETS problem. One of the very 
> first problems of interoperability that occurred with RETS1 was that 
> the internet standard RFC 2617, adopted June, 1999 was implemented 
> slightly differently by that other collection of phds, Microsoft, 
> where an optional field was made mandatory. Given that almost everyone 
> used third-party libraries for this function, the interoperability 
> problem was wide-spread and had nothing to do with RETS other than it 
> referenced the "standard" RFC 2617.
>
> I would also remind everyone of the ongoing issues between mail 
> servers and the work-around techniques used to resolve differences in 
> SMTP, POP and IMAP, all of which are well-known, old standards. This 
> is common within any standards community.
>
> Since this seems to be the nature of the beast - more flexibility 
> leads to less interoperability, we can clearly see the balance that 
> must be struck. Constrain the standard to improve the interoperability 
> at the cost of removing potential valuable flexibility to meet 
> business needs. While any balance struck must be imperfect, hopefully 
> we have got within an acceptable range with RETS2. Where possible, 
> RETS2 attempts to choose greater constraint over greater flexibility, 
> recognizing this short comings of the RETS1 document and compliance 
> process.
>