[Rets-dev] RETS 2.0 Discussions

[Paul Stusiak]

I think Sergio was pointing at a starting point. Over the last three or 
more years, the majority of the discussions at the meetings have 
centered around the engineering of RETS2. While there was a starting 
point, it moved over the years. The RET1.x on SOAP was discussed and the 
community moved on from that point.

There was a lot of participation on the architecture. In fact, if you 
were to ask some of those in attendance, you might find that there was 
too much at some meetings. While you have been a valuable part of the 
community over many years and I hope that you will continue to 
contribute new ideas and to challenge assumptions going forward, there 
was a period of time when you were absent from the industry. The work of 
RETS did continue during this time. Some of the decisions were made 
during this time. Please do not take this as an attempt to stop you from 
asking questions, only to recognize that things did happen when you 
weren't there.

If there are business cases that have been accidentally excluded, then 
please bring them up.

Your point about RETS2/RETS1 is not being ignored. Rather, I would leave 
it open and see where we go.

For those reading the thread looking for some more drama, keep moving, 
there is nothing here.

Stuart Schuessler wrote:
>
> I was at the meetings for RETS 2.0 so I am not sure what you are 
> talking about.
>
> I voted to move SOAP forward. I wanted to put a SOAP interface on RETS 
> 1.x. We were planning to do that. FORMAT= was going to be the payload 
> and there was to be a new metadata.
>
> I am not suggesting that the specification be thrown away. I am 
> suggesting that RETS 2.0 be a transaction management specification.
>
> >> I say let's work through the Payload issues and see if we can make 
> this work. There is likely a solution out there that will work for 
> everyone.
>
> OK, Let’s see, but the idea of making RETS 2.0 a transaction 
> management standard and RETS 1.x a MLS System standard is a valid 
> point if we are unable to come up with a solution otherwise. There 
> does not seem to be a great deal of interest though.
>
> I am not anti RETS 2.0. I would have liked to see it further along. I 
> am concerned that a lot of history and business use cases have been 
> ignored and will have to be put back into the specification. I am 
> concerned that there is not more participation in writing the 
> architecture, that basically it is left to a select few.
>
> I am most of all concerned that anytime someone has a dissenting view 
> of the world there are no less than 4 consultants that jump down their 
> throat. It is the same 4 that respond every time. Why is that?
>
> ------------------------------------------------------------------------
>
> *From:* Sergio Del Rio [mailto:Sergio.Del.Rio at t4bi.com]
> *Sent:* Tuesday, May 01, 2007 9:33 PM
> *To:* 'Stuart Schuessler'; 'RetsDev'
> *Subject:* RE: [Rets-dev] RETS 2.0 Discussions
>
> Stuart, you have to realize the we moved on after you stopped coming 
> to the RETS meetings. We made progress, we made changes, we had many, 
> many conference calls where RETS 2.0 was discussed, we had many 
> meetings where RETS 2.0 was discussed in detail, we reviewed and 
> re-reviewed the RETS 2.0 Specification until we were all happy with 
> it. Yes, we even realized that removing COMPACT out of 2.0 was, in 
> fact, a mistake for reasons which I believe are obvious based on 
> discussions so far today.
>
> The RETS 2.0 Specification was voted in as the correct direction for 
> reasons already stated several times.
>
> You were even quoted as being in favour of SOAP and wanting to adopt 
> it sooner, rather than later. Well, Web Services use SOAP as the 
> underlying protocol.
>
> The other quotes you have are so old that we were all, everyone in the 
> room in 2002, very cautious that actually trying to move to a 2.0 Web 
> Services and SOAP transport that long ago was probably not a good 
> idea. The tookits back then were practically non-existent never mind 
> providing for interoperability between .Net and Java. In later 
> meetings we opened the doors to potential options.
>
> Now, we are at the point where we have a full specification. Granted 
> we probably need to discuss Security a bit more and there is the issue 
> of the Payload documents. And there is also the issue of making Update 
> work as we all want it to. But the specification works and Update is 
> not much worse off than it was in the original specification really. 
> As you are aware, we are working hard to resolve all of these issues.
>
> The RETS 2.0 specification, if you take a look at the most recent 
> document, is a complete and workable solution. Other than Update, it 
> has everything that we need to use Web Services and get the same 
> results we used to get but it can be done with XML or with COMPACT in 
> a valid and predictable way.
>
> I think the specification has made great progress and should not be 
> simply thrown away because people can't agree on whether or not to put 
> strong typing into the payloads.
>
> I say let's work through the Payload issues and see if we can make 
> this work. There is likely a solution out there that will work for 
> everyone.
>
> Regards,
>
> Sergio Del Rio
>
> Templates 4 Business Inc.
>
[snip]

-- 
Paul Stusiak
Falcon Technologies Corp.