Archive for September 13th, 2005

libRETS 1.0.0b2 released

Submitted by Dave Dribin:

libRETS is cross-platform RETS client library written in C++. libRETS is under an open-source license. libRETS provides an abstraction layer making it easier for developers to get started in RETS. Developers can use libRETS as the basis for RETS clients on Windows, Mac OS X, Linux, and other operating systems.

Features

  • Provides access to login, logout, search, and get object.
  • Can be accessed from many platforms, including Visual C++ on Windows, and gcc on just about any flavor of Unix.

Version 1.0.0 beta 2 has been released:

http://www.crt.realtors.org/projects/rets/librets/

Changes in this version:

  • Add support for SQL quoted literals.
  • Add support for SQL table aliases.
  • Add support for SQL IN clause.
  • Fix bug parsing 512-byte XML documents.

ezRETS 0.9.5 released

ezRETS is an ODBC driver that connects to RETS servers. It is licensed under an open-source license. It allows ODBC-aware applications, such as Microsoft Office (Excel, Word,) to easily load data from a RETS compliant server using those applications built-in wizards and other tools.

Right now, we only have a binary version for windows, but that seems to be the most useful to the most people. For those who would like to see/edit/compile the source, the source is available via subversion as well as at the download page.

You can download it by visiting http://www.crt.realtors.org/projects/rets/ezrets/

Changes in this release
Bug fixes:

  • Fixed null-pointer dereference that resulted in a crash when given a non-existent Table name in SQLTable
  • Fixed null-pointer dereference that resulted in a crash when getting INT data through SQLGetInfo
  • Fixed null-pointer dereference that resulted in a crash on getting column attributes when pulling from an ezrets virtual table instead of “real” RETS data
  • Can now handle when a RETS Table/SQL Column has its Interpretation set to currency and is formatted with commas. (Fix for Metrolist.)
  • Unknown Metadata types now ignored.

Enhancements:

  • SQLExtendedScroll and SQLFetchScroll implemented. This allows PHP metadata functions (SQLTables/SQLColumns) to work.
  • SQLColumns now returns column names in alphabetical order.
  • Quoting in a SQL statement now supported
  • Table aliases now supported

Paperless Transactions

What would the world be like if we didn’t have standards for the web like HTTP or HTML. You can surely debate the respective “goodness” of these standards on many grounds (including compliance), but the truth is browsers are possible because of them. I don’t know about you, but if I needed a separate browser for each website I monitor, my life would be sheer …. well, let’s say more difficult than it is today.

Before I apply this simplistic web example it to our industry, I want to first go on record as being one of those individuals who believes that it will be very difficult to eliminate all of the paper from a real estate transaction. If you consider the adoption curve that will be needed, all it will take is one party who prefers to work from paper to derail the effort. Can things be improved from where they are right now? Absolutely. With that being said, hopefully much of the “flame-bait” elements of this post will be defused.

There are a group of vendors forming around a class of products called Transaction Management Systems (TMS). The promise of TMS is that it will provide document management and work flow to help organize the tremendous volume of paperwork of transactions. Those of you who do not follow this space closely may wonder “Why is work flow required?”. With the layers of regulatory, legislative and governance requirements experienced at a local level, it would be difficult to have one, national standard set of requirements regarding what is needed to transfer ownership of a property. TMS systems define what is required and when. Can you have TMS without work flow? Sure. But from what I have seen, the vendor community has their sights set higher.

There are already some early adopters (Brokers) going down the path of TMS. I applaud them for their courage and foresight and would not want to say anything here that discourages them. We need to avoid a second coming of the client/server model or a “one TMS, one browser” world though. I’m old enough to have lived through that once and integration was really challenging. It would be nice to have standards in place before wide scale adoption. Some of the interesting areas where standards could be applied are:

  • Service Orders - Requesting and getting the results of third party activities
  • Status - Nice not only for the Agents, but also the Client
  • Back Office Systems - Let’s eliminate another cut-and-paste issue
  • MLS Systems - Ditto the Back Office comment
  • LOS Systems - Can you detect a theme?

I see several areas where challenges remain in the standards approach. Electronic Signature recognition, Authentication and File Formats being only three. We can avoid a lot of churning by studying how other industries became electronic. There are some great lessons to learn from the Manufacturing segment who went from paper purchase orders to ERP in two decades. Although there were fewer parties involved in each transaction, they had a cascading effect to deal with. What helped them in the end were standards, not proprietary solutions.

The big win for our industry won’t be the amount of “cutting and pasting” that is eliminated, but what consumers think. Sure, back office operations will be more efficient, but if I can look up the status of my transaction whenever I want, at least one reason to loose sleep when buying a home will be eliminated. I will be looking for someone to thank and might not even miss the closing gift:)