rets-client - npm Package Versions

3.2.0

Version 3.2 passes through any multipart headers (except for content-disposition, which gets split up first; content-type which is renamed to mime; and content-transfer-encoding which is used internally and not passed) onto the objects resolved from client.objects.getPhotos(). It also fixes a race condition in client.objects.getPhotos().

3.1.0

Version 3.1 adds a response field to the object resolved from client.objects.getObject(), containing the full HTTP response object. It also fixes a major bug interfering with client.objects.getPhotos() and client.objects.getObject() calls.

3.0.0

Version 3.x is out! This represents a substantial rewrite of the underlying code, which should improve performance (both CPU and memory use) for almost all RETS calls by using node-expat instead of xml2js for xml parsing. The changes are mostly internal, however there is 1 small backward-incompatible change needed for correctness, described below. The large internal refactor plus even a small breaking change warrants a major version bump.

Version 3.x has almost the same interface as 2.x, which is completely different from 1.x. If you wish to continue to use the 1.x version, you can use the v1 branch.

Many of the metadata methods are capable of returning multiple sets of data, including (but not limited to) the getAll* methods. Versions 1.x and 2.x did not handle this properly; ~~version 1.x returns the values from the last set encountered~~, and version 2.x returns the values from the first set encountered. (This has been corrected in version 1.2.0.) Version 3.x always returns all values encountered, by returning an array of data sets rather than a single one.

In addition to the methods available in 2.x, version 3.0 adds client.search.stream.searchRets(), which returns a text stream of the raw XML result, and client.search.stream.query(), which returns a stream of low-level objects parsed from the XML. (See the streaming example below.) These streams, if used properly, should result in a much lower memory footprint than their corresponding non-streaming counterparts.