1) RETS specification contains requirements for clients as well as servers.
2) RETS community supported a client compliance program for four years.
3) RETS community never voted to disband client compliance.
4) Client Compliance was included in the RFP for the current server
compliance tool.
5) Current clients have no way to test if they will interoperate with the
newly mandated 1.7.2 servers.
6) Under the trademark and logo language, clients cannot display the RETS
logo because they have no way of certifying that their products are RETS
compliant.
7) Compliance workgroup has unanimously voted to offer client compliance
and discussed it at length.
Zeke
--
You received this message because you are subscribed to the Google Groups "RETS Compliance" group.
To post to this group, send email to rets-co...@googlegroups.com.
To unsubscribe from this group, send email to rets-complian...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rets-compliance?hl=en.
The RETS budget is still not approved and as of this moment we have no
funding for anything. We approved a motion that I sent to the BOD to
request that outstanding TRAC issues be fixed.
The high priority items in our budget request are client compliance and
re-architecting the server tool to allow for automated/easier addition of
tests.
Of crucial importance is not only that we get funding but that RESO has
control over how the funds are dispersed so we make the best use of our
monies this year.
1. Some MLSs require client compliance to verify the client app works with RETS. This reduces the need for the MLS to support ad hoc RETS debugging.
2. There are more RETS client apps than server apps.
3. RETS client-side developers often have less experience and less support with RETS than server side developers who are hired by larger organizations dedicated to supporting RETS.