Archive for September, 2005

VieleRETS 0.8.7 Released

Published
by
Mark Lesswing
on September 30, 2005
in Announcements, MLS and Projects
. 0 Comments

VieleRETS is a RETS client that downloads listings and is licensed under an open-source license. It can store data in XML, CVS or Relational Database format. VieleRETS as direct support for Open Realty.

The next version will have support for Open Realty 2.1 (hopefully).

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

Changes in this release

Bug fixes:

  • Batch processing at a more atomic level to avoid timeouts.
  • NULL queries now work correctly
  • CheckBox and Radio button bugs fixed
  • Configuration file bug fixed

Enhancements:

  • Auto-Detection now detects image settings
  • An additional step has been added to Auto-Detection to allow you to specify fields on query forms.
  • Auto-Detection now allows the User-Agent to be specified
  • Metadata caching has been enhanced to capture Resource, Class, Object, Lookup and Lookup_Type
  • Query forms can now be populated with server supplied values
  • Query form definition panel has more functions

Retriever 2.0.9 Released

Published
by
Mark Lesswing
on September 30, 2005
in Announcements, MLS and Projects
. 0 Comments

Retriever is a RETS client that renders HTML views of listings that is licensed under an open-source license. It generates Summary, Detail and Gallery views of listings stored on the MLS without making a local copy of the data.

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

Changes in this release

Bug fixes:

  • Batch processing at a more atomic level to avoid timeouts.
  • NULL queries now work correctly
  • CheckBox and Radio button bugs fixed
  • Configuration file bug fixed

Enhancements:

  • Auto-Detection now detects image settings
  • An additional step has been added to Auto-Detection to allow you to specify fields on query forms.
  • Auto-Detection now allows the User-Agent to be specified
  • Metadata caching has been enhanced to capture Resource, Class, Object, Lookup and Lookup_Type
  • Query forms can now be populated with server supplied values
  • Query form definition panel has more functions

Sounds like …

Published
by
Mark Lesswing
on September 28, 2005
in Off Topic, Reviews and Tools
. 0 Comments

Years in the making, Ardour 0.99 is finally released.

Audio work is something I got into when I began recording my my son (hey, he just got his first gig, Saturday night) and daughter in a effort to explore music education alternatives. The theory is that once the basics are in hand, students can learn faster by listening to themselves play. They become “self critical” without becoming angry at the instructor. They know a session “sucks” because they can hear it themselves. As a “toy” my six year old sings along with (karaoke style) Pink Floyd’s “The Wall”. It is hilarious to listen to him yell “Teacher! Leave them kids alone!”

Here is my own review of Ardour:

Ardour is a DAW (Digital Audio Workstation). You can get latency down to around 30 ms, even with software-based plug-in effects. The most popular (and fastest) Windows-based DAW (ProTools) can get latency down to around 90 ms for around $300. The trick to achieving this in Linux is using low-latency kernel processing (supported directly by 2.6). I have noticed that this configuration handles interrupts as kernel threads. If I run “top”, I see that the wait state for processing is always slightly above 1.0. When I first saw this, I thought something was wrong, but it is supposed to
be this way. With low latency processing, you can give priority to interrupt particular interrupt threads, like your sound card.

This is more than an sound editor (like Audacity), Ardour is a multi-track recorder with effects like an digital mixer. Effect plug-ins must support the LADSPA “standard” which gives you a couple of hundred from about 10 sources. Effects include the usual suspects (reverb, chorus, etc.). VST plug-ins from the Windows world (ProTools) can be supported with Wine.

Ardour supports sessions, auditioning and mixing with a multiple bus architecture just like digital mixers. I run a 24 bit sound card with four inputs and four outputs with no problem. I have four condenser microphones for input and use only two of the outputs (configured as right and left) for my control room monitor. In the future (when I can spend some more money), I will add headphone service to outputs three and four.

A full studio can be configured by using Rosegarden (MIDI Sequencer and SoftSynth), Hydrogen (drum kit) or Jamin (mastering tool). These tools can be used as input or output processes live via the Jack transport tools. Jack is like a giant, virtual “patch bay” (makes me think of Aubrey’s “switchboard” only “real time” and smaller).

As a stand alone, Ardour can export to .wav including TOC or CUE files for CD production. It cannot read ProTools format directly (proprietary file format), but can import .wav files exported by the tool.

Ardour has been ported to OS X too.

There will be no 1.0. The development was so delayed, they will go right to 2.0 which is a GTK 2 version. This should “spiff up” sliders and other controls a bit. The current version has a pleasing presentation though and the default theme is classic black. This makes the meters (lots of green, yellow and red) really standout.

Variman 2.1.7 released

Published
by
Keith Garner
on September 27, 2005
in Announcements and Projects
. 0 Comments

Submitted by Dave Dribin:

Variman is a RETS 1.0 and 1.5 compliant server. Variman is developed under a open source license.

Variman is built on Java technology as a web application using servlets.

Features

  • Certified RETS 1.0 and 1.5 compliant.
  • Cross platform. Runs on Microsoft Windows, Linux, Unix, Mac OS X, and anywhere else a 1.3 version of Java is available.
  • Minimal external intallation requirements. Embedded Tomcat version requires only Java and a relational database.
  • Supports PostgreSQL and Microsoft SQLServer with either the JNetDirect JSQLConnect driver or jTDS.

Changes in this version include:

  • Update rets-client to warn on metadata parse errors.
  • Report proper SYSTEM metadata version in Login transaction.
  • Decode to long values, then short values for COMPACT-DECODED.
  • Add option to roll log file over every week, instead of by size.
  • Make logging options configurable via administration GUI.
  • Add an optional separate log file just for logging DMQL and SQL only.
  • Add per-group time restrictions.

While normally I would recommend running the Window setup program without uninstalling first, I would highly suggest uninstalling any early versions of Variman before installing 2.1.7. You’re configuration should be left intact, but any log files will be removed. Make a backup of the following directory, just to be safe or to keep the log files:

  C:\Program Files\Variman RETS Server\

The version is available from the Variman home page:

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

The travail of travel – or look out what you ask for!

Published
by
Todd Costigan
on September 19, 2005
in Conferences
. 0 Comments

We at CRT have the pleasure to speak on technology topics at many REALTOR events. September is a busy month, with many state and local associations holding their annual conventions. Last week everyone in the group had a trip planned. CRT headed to the Dakotas, New York, Pennsylvania, Delaware and was canceled in Mississippi because of hurricane Katrina.

Its a great way for CRT to gain input and feedback from REALTORS and the meetings generally go off without issues. The local staff do an excellent job of making arrangements, you try not to get lost finding a site and both CRT and the audience comes away knowing more.

Once in a while though – we travel with computers to do presentation – the communication just doesn’t work. Last week – a projector was requested for one of the presentations. And there was a projector provided. However, it was an overhead projector.

Well the local staff did a great job of scrambling and the REALTORS session came off without a hitch. Its easy to smile about it now, but I’ll be sure to be clear the next time I request a projector.

Would you like to have CRT speak at your next REALTOR event? If so contact us at: info@crt.realtors.org

What is RETS?

Published
by
Mark Lesswing
on September 15, 2005
in MLS, Projects and Security
. 3 Comments

A recent comment on this blog by John Lockwood (and a nudge by Keith Garner) pointed out that many people in the industry do not know what RETS is. Our posts often refer to it, and now I feel bad that we never defined it. If I could do it over again, I would have made this post early in the process. My apologies for the oversight.

RETS stands for Real Estate Transaction Standard. It defined an approach for exchanging listing with an MLS and is supported by and industry group known as RETS Working Group. The group was first formed in 2000 and is made up of vendors, MLS staff, REALTORS®, Association staff and others interested in standards. Requests and responses are both encapsulated in XML Format.

Meetings are held several times per year and anyone is invited. Those who attend get to vote on change proposals. The last meeting held in Chicago (August) had over 50 participants. The next meeting will be in Las Vegas in December. Typically, the first day of the three day meeting is dedicated to a “plugfest” where technical staffs from server and client vendors test interoperability. If you are developing solutions right now and would like to work directly with other vendors to work on interoperability, this day is well worth the time. The second day is dedicated to subgroup work like Marketing, Compliance, Data Dictionary and other standards areas. Day three concludes the event with subgroup reports and change proposals.

The current version of the RETS specification is 1.7. Solution providers who pass a compliance testing suite are allowed to use the designation RETS Compliant. In order to be compliant, a solution must support the current level of the specification or a previous version. Before version 1.7, the published version was 1.5. This means that a RETS Compliant Solution needs to support version 1.5 or 1.7 of the specification.

Now I will list a few things I have heard about RETS and offer commentary:

  • “My solution RETS Compliant to the 1.0 level of the specification” – Don’t be taken in, it just can’t be true, Refer to my compliance comments above.
  • “RETS is not secure” (context 1) – RETS uses Digest Authentication, pretty good stuff when done correctly. The biggest hurdle faced by solution providers is found in this area. Refer to my “plugfest” comments above.
  • “RETS is not secure” (context 2) – Sharing account and passwords is a operational issue. Some organizations require passwords to changed periodically. A simple and cheap solution.
  • “RETS is not secure” (context 3) – Digest Authentication is the default authentication mechanism. There is nothing that stops you from investing in two-factor authentication or other mechanisms (yikes, even Basic Authentication).
  • “RETS is not secure” (context 4) – I think there are huge problems with DRM. Try field level encryption and keep an eye on your performance meters. You could also put a special client on each desktop. If it disables hardware, I hope the solution is completely “bug free” for consumers (I purchased software once, early in my career, because it promised to have no bugs).
  • “I use my browser as a RETS client” – Both RETS and browsers rely on HTTP, but there are specific headers and response structures which RETS requires. Download the spec and check it out.
  • “Each MLS that supports RETS has different field names” – There are Standard Names defined in the specification but most MLS operators do not map them. This is an operational issue; they are defined in the spec.
  • “RETS is not available” – Not true. All of the major MLS vendors I know of have RETS capability. Regional MLS operators who write their own systems even support RETS.
  • “We know all about RETS because we practically wrote the specification” – I hear this a lot. Hundreds of people have contributed to the spec. Only solutions that are RETS compliant are, well, compliant.
  • “FTP feeds are easier than RETS” – A true statement if you look at short term only. Data fields change periodically forcing changes on the client end. If you are a REALTOR®, why would you invest in solutions for your business from vendors who spend most of their development budget reacting to changes. Nailing hundreds of custom feeds is really hard and expensive. Imagine a world with a custom browser for each website.
  • “RETS exposes all my members’ data” – This may have been true early on (refer to my compliance comments), but there are RETS servers with business rule support that limit “what is exposed to whom at what time of day”. Look for business rule features.
  • RETS is not perfect – This one is true!

Well I succeeded in turning a introduction into a diatribe (again).

libRETS 1.0.0b2 released

Published
by
Keith Garner
on September 13, 2005
in Projects
. 5 Comments

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

Published
by
Keith Garner
on September 13, 2005
in Announcements and Projects
. 0 Comments

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

Published
by
Mark Lesswing
on September 13, 2005
in MLS, Security and Tools
. 4 Comments

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:)

Greg Malone

Published
by
Mark Lesswing
on September 12, 2005
in General
. 0 Comments

I reflected yesterday on the good times I had with Greg Malone. I miss you.

This is off topic with regards to technology, but I have the ability to post so I took the opportunity.

« Older Entries