Our code developed while at the NAR RESO conference, given the discussion, demos of and specs about odata v3 for realty are at https://onedrive.live.com/redir?resid=5061D4609325B60!7154&authkey=!AB89Ln6T5oX7_TE&ithint=file%2c.zip
rather than doing the obvious and trivially easy work (just an odata controller to the mobile service project auto-created by visual studio 2012 updated),, we based this on the latest, beta webapi 2.2, for odata v4 – built per instructions in various blog posts. Uses static metadata in a manner that suits mobile clients; and allows for all the new features of odata v4 (including aliasing, that pertains to standard vs local naming).
Should a MLS data owner change the schema of the entities (as reflected in the metadata for the version of the service), one expects the rev the mobile app downloaded to the phone/device. Should add the nth local name for a standard field, one adds an alias.
A nice feature of the odata is the ability for a URI to invoke a “stored procedure” – a pre-validated and optimized odata query that is that is all tuned up for a given broker say.
There are the kinds of competitive advantages we can deploy against other vendors, once the standard moves past pre-competitive standardization and onto the competitive phase where value add and price matter more.
Of course, I expect to give away odata “feature” to customer at no charge (as with RETS) – if for nothing else to deny others “revenue per feature”. I can envision charging for the raw data transfer, however, now its easy to monitor who is use how many packets, at known $ per packet.