cart-users — CART User discussion and help

Re: [Cart-users] Fetching Photos with GetObjectRequest

[James W. <jw....@gm...>]

The answer:  Don't use Writers.  I changed
           FileWriter writer = new FileWriter(tempFile);
to
            FileOutputStream writer = new FileOutputStream(tempFile);

I should have noticed that the file size did not match (more than double)
that of the content-length header in the response.

-James

On Thu, Jul 31, 2008 at 7:21 AM, James Wilson <jw....@gm...> wrote:

> I'm having trouble getting the photo to write to disk.  I can't see in this
> code snippet what might be wrong about how I'm using the rets-client API.
> This is from a unit test that I'm using as an "exploration test" to confirm
> I'm using the rets-client api correctly against this Rapattoni RETS
> service.  So you can see from the assert that the RETS service says the
> image is a jpeg.  Gimp reports that the file "Not a JPEG file: starts with
> 0xef 0xbf".  I've tried Photos from a couple different listings with the
> same results.  Could someong please confirm that I'm using the
> GetObjectResponse correctly?
>
> -James
>
>         ...snip...
>         GetObjectResponse objectResponse =
> session.getObject(getObjectRequest);
>
>         Assert.assertEquals("image/jpeg", objectResponse.getType());
>
>         GetObjectIterator getObjectIterator = objectResponse.iterator();
>         while (getObjectIterator.hasNext()) {
>             SingleObjectResponse singleObjectResponse =
> getObjectIterator.next();
>
>             Assert.assertEquals("image/jpeg",
> singleObjectResponse.getType());
>             Assert.assertEquals(resourceEntity,
> singleObjectResponse.getContentID());
>
>             InputStream inputStream =
> singleObjectResponse.getInputStream();
>             BufferedInputStream bis = new BufferedInputStream(inputStream);
>
>             File tempFile = File.createTempFile("rets_test_photo",
> ".jpeg");
>             FileWriter writer = new FileWriter(tempFile);
>
>             int b = -1;
>             while ((b = bis.read()) != -1) {
>                 writer.write((byte) b);
>                 System.out.print(".");
>             }
>             System.out.println();
>             writer.close();
>         }
>         ...snip...
>

[Cart-users] Fetching Photos with GetObjectRequest

[James W. <jw....@gm...>]

I'm having trouble getting the photo to write to disk.  I can't see in this
code snippet what might be wrong about how I'm using the rets-client API.
This is from a unit test that I'm using as an "exploration test" to confirm
I'm using the rets-client api correctly against this Rapattoni RETS
service.  So you can see from the assert that the RETS service says the
image is a jpeg.  Gimp reports that the file "Not a JPEG file: starts with
0xef 0xbf".  I've tried Photos from a couple different listings with the
same results.  Could someong please confirm that I'm using the
GetObjectResponse correctly?

-James

        ...snip...
        GetObjectResponse objectResponse =
session.getObject(getObjectRequest);

        Assert.assertEquals("image/jpeg", objectResponse.getType());

        GetObjectIterator getObjectIterator = objectResponse.iterator();
        while (getObjectIterator.hasNext()) {
            SingleObjectResponse singleObjectResponse =
getObjectIterator.next();

            Assert.assertEquals("image/jpeg",
singleObjectResponse.getType());
            Assert.assertEquals(resourceEntity,
singleObjectResponse.getContentID());

            InputStream inputStream = singleObjectResponse.getInputStream();
            BufferedInputStream bis = new BufferedInputStream(inputStream);

            File tempFile = File.createTempFile("rets_test_photo", ".jpeg");
            FileWriter writer = new FileWriter(tempFile);

            int b = -1;
            while ((b = bis.read()) != -1) {
                writer.write((byte) b);
                System.out.print(".");
            }
            System.out.println();
            writer.close();
        }
        ...snip...

Re: [Cart-users] Trying to Get Started

[Dave D. <dr...@cr...>]

On May 23, 2005, at 6:29 PM, RETemp wrote:
> In any event, ezRETS looks like a much better solution. I currently use
> ODBC from Microsoft Excel and Access to connect to a SQL server. If
> ezRETS requires no more technical expertise than that, maybe I've 
> lucked
> out. If not, I'm going to have to get some help. But it's a lot better
> than starting from scratch.

ezRETS should be usable from Excel and Access the same as any ODBC 
driver, so I think this will be the best solution for you.  There will 
be some limitations, as RETS is not as powerful as a SQL database (for 
example, joins are not supported), but our aim is for Excel Access 
users to use RETS through ODBC.  Keep watching for the first release of 
the driver.

-Dave

Re: [Cart-users] Trying to Get Started

[Dave D. <dr...@cr...>]

On May 12, 2005, at 5:28 PM, RETemp wrote:
> Our department receives monthly housing data from about 90 
> Associations of REALTORS (AORs) throughout California. We already have 
> a system that accepts Excel (.csv) files of MLS records as input. Each 
> record contains about 70 data fields such as property type, status of 
> listing, selling price, days on market, etc. Since many of the AORs 
> are in the process of installing RETS-compliant servers, we would like 
> to begin collecting our monthly data from them using a RETS client. 
> Does Cart sound like a good choice for this?

First off, sorry for the late reply.  I have been out of the office 
quite a bit in the last few weeks.

Cart is not actively supported by CRT anymore.  If it works in it's 
current form then, great.  But CRT is not doing any more work on it, 
including bug fixes and feature enhancements.  I would not recommend it 
for any new applications.

You may want to look at ezRETS, our RETS ODBC driver:

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

It is still in the early stages of development, but we hope to have 
something usable for non-programmers relatively soon.  But you will 
still have to be fairly technically include to use ODBC.  If you have 
access to programmers, you could use our Java or C++ RETS library to 
write a custom application:

   C++ library (librets):
   http://www.crt.realtors.org/projects/rets/librets/

   Java RETS client:
   http://cart.sourceforge.net/documentation/rets-client/

librets has not had an official release, yet, but again, we hope to 
have one soon.  The Java RETS client is used by third party RETS 
developers.

> I have downloaded, installed, and launched Cart on my computer, and 
> one question already confronts me. Before giving me permission to 
> access its server (a Rapattoni MLS), the people who run the server 
> want me to tell them the value for "User-Agent" that my client is 
> sending. What should I tell them?

The user agent should be "Cart/1.0beta2"

-Dave

[Cart-users] RE: Trying to Get Started

[RETemp <re...@ca...>]

A support person from Rapattoni captured my failed login session and
determined that the "User-Agent" passed by Cart is Cart/1.0beta3rc1.

So, that hurdle is passed, and I will see if I can figure out how to use
this application.

> Thanks!
>=20
> Ron Pisaturo
> California Association of REALTORS(r)
> 525 South Virgil Avenue
> Los Angeles, California  90020
> Phone: (213) 739-8338=20
> Email: re...@ca...
>=20

[Cart-users] Trying to Get Started

[RETemp <re...@ca...>]

Hi, All--

I am a non-technical, RETS-virginal user in the Research & Economics of
the California Association of REALTORS. I would like to find out if Cart
is a good choice for meeting my simple needs, which I"ll describe.

Our department receives monthly housing data from about 90 Associations
of REALTORS (AORs) throughout California. We already have a system that
accepts Excel (.csv) files of MLS records as input. Each record contains
about 70 data fields such as property type, status of listing, selling
price, days on market, etc. Since many of the AORs are in the process of
installing RETS-compliant servers, we would like to begin collecting our
monthly data from them using a RETS client. Does Cart sound like a good
choice for this?=20

I have downloaded, installed, and launched Cart on my computer, and one
question already confronts me. Before giving me permission to access its
server (a Rapattoni MLS), the people who run the server want me to tell
them the value for "User-Agent" that my client is sending. What should I
tell them?

Perhaps the above question will give you all a clue of the other kinds
of questions that I will run into, and whether I have the technical
ability to use this application.

Thanks!

> Ron Pisaturo
> California Association of REALTORS(r)
> 525 South Virgil Avenue
> Los Angeles, California  90020
> Phone: (213) 739-8338=20
> Email: re...@ca...
>=20

[Cart-users] CART and format of Response from search queries

[Frank K. <fku...@to...>]

Hello,

When requesting search results in COMPACT or COMPACT-DECODED format, the
RETS server is expected to respond with a single <COLUMNS> tag and a
<DATA> tag for each row returned.
Within each of these tags, the columns are separated by the field
delimiter contained in the <DELIMITER> tag. This is all delineated in
section 7.6 of the RETS 1.5 specification.
Logically, there should be the same number of columns in each <DATA> tag
as there are in the <COLUMNS> tag.
But one vendor's RETS server includes an extra delimiter in each <DATA>
tag, resulting in an off-by-one column count in each <DATA> element WRT
the <COLUMNS> element.
Since the extra delimiter as at the end of each <DATA> tag, the column
alignment is not hosed, but the CART library expressly checks the column
count on each <DATA> element and will throw a SAXParseException if there
are too many data columns relative to the <COLUMNS> element.
(SearchResultHandler.endElement() )

My questions:
1. Is this server behavior a violation of the RETS Specification? It
seems that it should be a violation but I can't find it addressed
anywhere.
2. How would you handle this? I have modified CART to log an error
rather than throw an exception in this case, but I'm not sure how much
pressure I should put on the vendor concerning this. IMHO, it's very bad
practice, but if it's not a violation of the specification...

Thanks in advance,

-- 
Frank Kurzawa <fku...@to...>
Topaz Software, Inc.

Re: [Cart-users] RE: Cart-users digest, Vol 1 #26 - 4 msgs

[Dave D. <dr...@cr...>]

On Nov 10, 2004, at 6:39 PM, Jeffery A. Brush wrote:
> Dave wrote:
>
>> Rigorous testing digest authentication would be nice.  I can't tell 
>> you how
>> many times I get questions regarding digest auth and problems some 
>> client
>> writers tend to have.
>
> This is part of the reason we swapped out our custom code for 
> HttpClient for
> our client API. Do you see this as a client problem or a server 
> problem? And
> any specifics?

There's issues on both the client and server, but I was specifically 
talking about clients being very loose in interpreting the spec.

> Things we have run into include:
> 	stale nounce - (We sent a patch to HttpClient fixing this.)
> 	missing qop
> 	confusion about when cookies are returned

Other things to include:

   - Check for increasing nc (nonce count).  It should never be repeated 
or decrease.

   - Incorrect quotes in Authorization header.  Both qop and nc are not 
supposed to have quotes.  But you often see qop="auth" which is 
incorrect.

   - Incorrectly matching of uri field to actual URI.  I've seen clients 
put the login URI in the authorization header for every digest 
Authorization header, even when executing other transactions.

   - Putting an equals sign in the opaque field (for testing clients) 
and the cnonce field (for testing servers).  Some parsers assume equals 
only occur between key/value pairs.  But you can get equals signs in 
both opaque and cnonce.

   - Servers need to handle the case when clients do not set qop.  The 
digest is then calculated differently.

And as far as a general HTTP problem I've seen multiple times is 
incorrectly setting the "Host" HTTP header.  Hand-written clients often 
do not set the port in the Host header.  For example, if the client is 
trying to access:

   http://rets.example.com:6103/login

Then the host header should be as follows:

   Host: rets.example.com:6103

I've seen many clients forget the port.  This confuses some HTTP 
servers.

Hope that helps.

-Dave

[Cart-users] RE: Cart-users digest, Vol 1 #26 - 4 msgs

[Jeffery A. B. <jb...@ea...>]

Dave wrote:

>Rigorous testing digest authentication would be nice.  I can't tell you how
>many times I get questions regarding digest auth and problems some client
>writers tend to have.

This is part of the reason we swapped out our custom code for HttpClient for
our client API. Do you see this as a client problem or a server problem? And
any specifics?

Things we have run into include:
	stale nounce - (We sent a patch to HttpClient fixing this.)
	missing qop
	confusion about when cookies are returned


-----Original Message-----
From: car...@li...
[mailto:car...@li...] On Behalf Of
car...@li...
Sent: Tuesday, November 09, 2004 11:07 PM
To: car...@li...
Subject: Cart-users digest, Vol 1 #26 - 4 msgs

Send Cart-users mailing list submissions to
	car...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/cart-users
or, via email, send a message with subject or body 'help' to
	car...@li...

You can reach the person managing the list at
	car...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cart-users digest..."


Today's Topics:

   1. Compliance Tests (Jeffery A. Brush)
   2. Re: Compliance Tests (Dave Dribin)
   3. Re: Compliance Tests (David Steinbrunner)
   4. RE: Compliance Tests (Jeffery A. Brush)

--__--__--

Message: 1
From: "Jeffery A. Brush" <jb...@ea...>
To: <car...@li...>
Date: Tue, 9 Nov 2004 11:17:23 -0500
Subject: [Cart-users] Compliance Tests

Hi all,

NAR has asked Avantia to "raiser the bar" on RETS compliance tests and we're
looking for issues from users familiar with RETS Clients and Servers, which
we can roll into one of the next rounds of RETS tests.

The issues that have been recently mentioned on this list include:
	1. Bad case for capability url keys.
	2. Undocumented capability url keys.
	3. Incorrect logout response.
	4. Bad xml in the search results. 
	(This one is tricky to test for as we only see a subset of content.)

If anyone has anything else they would like to see tested for on the server
or client side, please let me know and I'll try to get it added to the test
suite.


Thanks,

Jeff Brush
Avantia, Inc.
jb...@ea...




--__--__--

Message: 2
From: Dave Dribin <dr...@cr...>
Subject: Re: [Cart-users] Compliance Tests
Date: Tue, 9 Nov 2004 12:21:43 -0600
To: <car...@li...> <car...@li...>
<car...@li...>

On Nov 9, 2004, at 10:17 AM, Jeffery A. Brush wrote:
> Hi all,
>
> NAR has asked Avantia to "raiser the bar" on RETS compliance tests and 
> we're
> looking for issues from users familiar with RETS Clients and Servers, 
> which
> we can roll into one of the next rounds of RETS tests.

Excellent!

> The issues that have been recently mentioned on this list include:
> 	1. Bad case for capability url keys.
> 	2. Undocumented capability url keys.
> 	3. Incorrect logout response.
> 	4. Bad xml in the search results.
> 	(This one is tricky to test for as we only see a subset of content.)

As far as #4 goes... I wish we could test this somehow.  Is there a way 
to force servers to pre-load some known data?  Maybe utilize this for 
servers that support standard names or something?

> If anyone has anything else they would like to see tested for on the 
> server
> or client side, please let me know and I'll try to get it added to the 
> test
> suite.

Rigorous testing digest authentication would be nice.  I can't tell you 
how many times I get questions regarding digest auth and problems some 
client writers tend to have.

-Dave



--__--__--

Message: 3
Date: Tue, 09 Nov 2004 16:21:54 -0500
Subject: Re: [Cart-users] Compliance Tests
From: David Steinbrunner <ca...@po...>
To: "Jeffery A. Brush" <jb...@ea...>,
   <car...@li...>

> Hi all,
> 
> NAR has asked Avantia to "raiser the bar" on RETS compliance tests and
we're
> looking for issues from users familiar with RETS Clients and Servers,
which
> we can roll into one of the next rounds of RETS tests.
> 
> The issues that have been recently mentioned on this list include:
> 1. Bad case for capability url keys.
> 2. Undocumented capability url keys.
> 3. Incorrect logout response.
> 4. Bad xml in the search results.
> (This one is tricky to test for as we only see a subset of content.)
> 
> If anyone has anything else they would like to see tested for on the
server
> or client side, please let me know and I'll try to get it added to the
test
> suite.

My company currently has two big issues with RETS.

The biggest would be the lack of support for standard names.  Our client
currently supports two MLS vendors servers which requires us to have large
blocks of code to handle the same data but with different names because of
the lack of standard names or different "standard" names for the same thing
by different vendors.  We are currently looking to add support for more MLS
vendors but do not look forward to having to deal with more inconsistent
naming conventions.

The second is a specific issue with one vendor where results in STANDARD-XML
do not give us all the data fields so we have to use COMPACT. The problem is
that COMPACT is sent as content-type 'text/plain' without encoded data
rather than content-type 'text/xml' with encoded data, as you would expect
from an XML based system.  As with issue 4 above this will make any XML
parser 'blow chunks' unless you add special handling for such cases.

Better compliance tests are greatly needed to make RETS more approachable,
easier to create and maintain.

Thanks for the opportunity to unload that on the list ;-P

-- 
David Steinbrunner
MFM Communication Software, Inc.
http://www.mfm.com




--__--__--

Message: 4
From: "Jeffery A. Brush" <jb...@ea...>
To: <car...@li...>
Subject: RE: [Cart-users] Compliance Tests
Date: Tue, 9 Nov 2004 19:48:29 -0500


Hello David,

Thanks for your response!  I actually have some good news for you regarding
your issues and our planned compliance testing.

Standard Names support (or lack thereof) has been a big concern in the RETS
community.  As such, compliance tests are requiring that servers support a
defined subset of standard names going forward.  This is already in
progress.

Requiring mapping more fields to standard-xml is the next step after
standard names support.  We are going to doublecheck that standard names
support extends to the mapping of those standard names within the
appropriate standard-xml elements.  

One additional note about COMPACT:  if you are accessing a 1.5 server, it is
required that ALL responses be well-formed XML, i.e., have a content type of
text/xml AND be parsed by an XML parser.  The COMPACT responses from those
servers should be adhering to this or they are already NOT RETS compliant.  

--Jeff


-----Original Message-----
From: David Steinbrunner [mailto:ca...@po...] 
Sent: Tuesday, November 09, 2004 4:22 PM
To: Jeffery A. Brush; car...@li...
Subject: Re: [Cart-users] Compliance Tests

> Hi all,
> 
> NAR has asked Avantia to "raiser the bar" on RETS compliance tests and
we're
> looking for issues from users familiar with RETS Clients and Servers,
which
> we can roll into one of the next rounds of RETS tests.
> 
> The issues that have been recently mentioned on this list include:
> 1. Bad case for capability url keys.
> 2. Undocumented capability url keys.
> 3. Incorrect logout response.
> 4. Bad xml in the search results.
> (This one is tricky to test for as we only see a subset of content.)
> 
> If anyone has anything else they would like to see tested for on the
server
> or client side, please let me know and I'll try to get it added to the
test
> suite.

My company currently has two big issues with RETS.

The biggest would be the lack of support for standard names.  Our client
currently supports two MLS vendors servers which requires us to have large
blocks of code to handle the same data but with different names because of
the lack of standard names or different "standard" names for the same thing
by different vendors.  We are currently looking to add support for more MLS
vendors but do not look forward to having to deal with more inconsistent
naming conventions.

The second is a specific issue with one vendor where results in STANDARD-XML
do not give us all the data fields so we have to use COMPACT. The problem is
that COMPACT is sent as content-type 'text/plain' without encoded data
rather than content-type 'text/xml' with encoded data, as you would expect
from an XML based system.  As with issue 4 above this will make any XML
parser 'blow chunks' unless you add special handling for such cases.

Better compliance tests are greatly needed to make RETS more approachable,
easier to create and maintain.

Thanks for the opportunity to unload that on the list ;-P

-- 
David Steinbrunner
MFM Communication Software, Inc.
http://www.mfm.com





--__--__--

_______________________________________________
Cart-users mailing list
Car...@li...
https://lists.sourceforge.net/lists/listinfo/cart-users


End of Cart-users Digest

Re: [Cart-users] Re: When good headers go bad

[Frank K. <fku...@to...>]

Umm, yes.

I thought that would probably be the answer...  :(

Onward through the fog. 

F.

On Wed, 2004-11-10 at 16:05, Dave Dribin wrote:
> On Nov 10, 2004, at 3:51 PM, Frank Kurzawa wrote:
> > I would like to tell org.apache.commons.httpclient.HttpClient to ignore
> > this rather than throwing an exception, but it's not clear to me what
> > would be the simplest way.
> 
> You can't.  HttpClient cannot be told to handle this.  It always throws 
> an exception if it cannot parse the HTTP headers.  You could modify 
> commons-httpclient, I suppose.  It is open source, after all.
> 
> -Dave
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Cart-users mailing list
> Car...@li...
> https://lists.sourceforge.net/lists/listinfo/cart-users
-- 
Frank Kurzawa <fku...@to...>
Topaz Software, Inc.

[Cart-users] Re: When good headers go bad

[Dave D. <dr...@cr...>]

On Nov 10, 2004, at 3:51 PM, Frank Kurzawa wrote:
> I would like to tell org.apache.commons.httpclient.HttpClient to ignore
> this rather than throwing an exception, but it's not clear to me what
> would be the simplest way.

You can't.  HttpClient cannot be told to handle this.  It always throws 
an exception if it cannot parse the HTTP headers.  You could modify 
commons-httpclient, I suppose.  It is open source, after all.

-Dave

[Cart-users] When good headers go bad

[Frank K. <fku...@to...>]

I'm trying to retrieve objects from a RETS server.

I get a HttpRecoverableException: org.apache.commons.httpclient.HttpException: Unable to parse header: MIME-Version 1.0

Apparently the server is leaving out the ":" between the MIME-VERISION
and the 1.0.

I would like to tell org.apache.commons.httpclient.HttpClient to ignore
this rather than throwing an exception, but it's not clear to me what
would be the simplest way. Do I need to be modifying
org.realtors.rets.client.CommonsHttpClient()?

Thanks,

-- 
Frank Kurzawa <fku...@to...>
Topaz Software, Inc.

RE: [Cart-users] Compliance Tests

[Jeffery A. B. <jb...@ea...>]

Hello David,

Thanks for your response!  I actually have some good news for you regarding
your issues and our planned compliance testing.

Standard Names support (or lack thereof) has been a big concern in the RETS
community.  As such, compliance tests are requiring that servers support a
defined subset of standard names going forward.  This is already in
progress.

Requiring mapping more fields to standard-xml is the next step after
standard names support.  We are going to doublecheck that standard names
support extends to the mapping of those standard names within the
appropriate standard-xml elements.  

One additional note about COMPACT:  if you are accessing a 1.5 server, it is
required that ALL responses be well-formed XML, i.e., have a content type of
text/xml AND be parsed by an XML parser.  The COMPACT responses from those
servers should be adhering to this or they are already NOT RETS compliant.  

--Jeff


-----Original Message-----
From: David Steinbrunner [mailto:ca...@po...] 
Sent: Tuesday, November 09, 2004 4:22 PM
To: Jeffery A. Brush; car...@li...
Subject: Re: [Cart-users] Compliance Tests

> Hi all,
> 
> NAR has asked Avantia to "raiser the bar" on RETS compliance tests and
we're
> looking for issues from users familiar with RETS Clients and Servers,
which
> we can roll into one of the next rounds of RETS tests.
> 
> The issues that have been recently mentioned on this list include:
> 1. Bad case for capability url keys.
> 2. Undocumented capability url keys.
> 3. Incorrect logout response.
> 4. Bad xml in the search results.
> (This one is tricky to test for as we only see a subset of content.)
> 
> If anyone has anything else they would like to see tested for on the
server
> or client side, please let me know and I'll try to get it added to the
test
> suite.

My company currently has two big issues with RETS.

The biggest would be the lack of support for standard names.  Our client
currently supports two MLS vendors servers which requires us to have large
blocks of code to handle the same data but with different names because of
the lack of standard names or different "standard" names for the same thing
by different vendors.  We are currently looking to add support for more MLS
vendors but do not look forward to having to deal with more inconsistent
naming conventions.

The second is a specific issue with one vendor where results in STANDARD-XML
do not give us all the data fields so we have to use COMPACT. The problem is
that COMPACT is sent as content-type 'text/plain' without encoded data
rather than content-type 'text/xml' with encoded data, as you would expect
from an XML based system.  As with issue 4 above this will make any XML
parser 'blow chunks' unless you add special handling for such cases.

Better compliance tests are greatly needed to make RETS more approachable,
easier to create and maintain.

Thanks for the opportunity to unload that on the list ;-P

-- 
David Steinbrunner
MFM Communication Software, Inc.
http://www.mfm.com

Re: [Cart-users] Compliance Tests

[David S. <ca...@po...>]

> Hi all,
> 
> NAR has asked Avantia to "raiser the bar" on RETS compliance tests and we're
> looking for issues from users familiar with RETS Clients and Servers, which
> we can roll into one of the next rounds of RETS tests.
> 
> The issues that have been recently mentioned on this list include:
> 1. Bad case for capability url keys.
> 2. Undocumented capability url keys.
> 3. Incorrect logout response.
> 4. Bad xml in the search results.
> (This one is tricky to test for as we only see a subset of content.)
> 
> If anyone has anything else they would like to see tested for on the server
> or client side, please let me know and I'll try to get it added to the test
> suite.

My company currently has two big issues with RETS.

The biggest would be the lack of support for standard names.  Our client
currently supports two MLS vendors servers which requires us to have large
blocks of code to handle the same data but with different names because of
the lack of standard names or different "standard" names for the same thing
by different vendors.  We are currently looking to add support for more MLS
vendors but do not look forward to having to deal with more inconsistent
naming conventions.

The second is a specific issue with one vendor where results in STANDARD-XML
do not give us all the data fields so we have to use COMPACT. The problem is
that COMPACT is sent as content-type 'text/plain' without encoded data
rather than content-type 'text/xml' with encoded data, as you would expect
from an XML based system.  As with issue 4 above this will make any XML
parser 'blow chunks' unless you add special handling for such cases.

Better compliance tests are greatly needed to make RETS more approachable,
easier to create and maintain.

Thanks for the opportunity to unload that on the list ;-P

-- 
David Steinbrunner
MFM Communication Software, Inc.
http://www.mfm.com

Re: [Cart-users] Compliance Tests

[Dave D. <dr...@cr...>]

On Nov 9, 2004, at 10:17 AM, Jeffery A. Brush wrote:
> Hi all,
>
> NAR has asked Avantia to "raiser the bar" on RETS compliance tests and 
> we're
> looking for issues from users familiar with RETS Clients and Servers, 
> which
> we can roll into one of the next rounds of RETS tests.

Excellent!

> The issues that have been recently mentioned on this list include:
> 	1. Bad case for capability url keys.
> 	2. Undocumented capability url keys.
> 	3. Incorrect logout response.
> 	4. Bad xml in the search results.
> 	(This one is tricky to test for as we only see a subset of content.)

As far as #4 goes... I wish we could test this somehow.  Is there a way 
to force servers to pre-load some known data?  Maybe utilize this for 
servers that support standard names or something?

> If anyone has anything else they would like to see tested for on the 
> server
> or client side, please let me know and I'll try to get it added to the 
> test
> suite.

Rigorous testing digest authentication would be nice.  I can't tell you 
how many times I get questions regarding digest auth and problems some 
client writers tend to have.

-Dave

[Cart-users] Compliance Tests

[Jeffery A. B. <jb...@ea...>]

Hi all,

NAR has asked Avantia to "raiser the bar" on RETS compliance tests and we're
looking for issues from users familiar with RETS Clients and Servers, which
we can roll into one of the next rounds of RETS tests.

The issues that have been recently mentioned on this list include:
	1. Bad case for capability url keys.
	2. Undocumented capability url keys.
	3. Incorrect logout response.
	4. Bad xml in the search results. 
	(This one is tricky to test for as we only see a subset of content.)

If anyone has anything else they would like to see tested for on the server
or client side, please let me know and I'll try to get it added to the test
suite.


Thanks,

Jeff Brush
Avantia, Inc.
jb...@ea...

Re: [Cart-users] Re: Some issues with CART and non-compliant servers

[Frank K. <fku...@to...>]

On Mon, 2004-11-08 at 10:52, Dave Dribin wrote:

> Okay... which RETS server are you using?  They are terribly sloppy, and 
> should not be allowed to use the word "RETS" when describing their 
> product.
> 
> -Dave

Oops. I forgot to answer this. All the problems that I've described so far are 
with the actris system in Austin, TX. 

The problems so far:
1. Bad case for capability url keys. ("GETOBJECT" instead of "GetObject", etc.).
2. Undocumented capability url keys.
3. Incorrect logout response.
4. Bad xml in the search results (ampersands appearing in listing text).

Regards,

Frank

Re: [Cart-users] Re: Some issues with CART and non-compliant servers

[Dave D. <dr...@cr...>]

On Nov 8, 2004, at 2:51 PM, Michael Breathes wrote:
> This is too true. Can CRT or someone else have those that are not
> compliant remove anything saying they are?

There are people on the RETS committee doing just this.  But if no one 
informs them, then the offenders just get away with it.

> ARIS, our MLS provider here, makes that claim on their site as well as
> verbally, but when I would call to get the login URL, they said there
> wasn't one. Hmmmm.

Well, I'm not sure I understand the whole situation, but they may still 
be RETS compliant and not give you access to the server.  Being RETS 
compliant does not require an MLS to give out RETS accounts to anyone 
that asks.  An MLS may have certain policies in place, and that is 
beyond RETS compliancy (which only refers to the technical aspect of 
RETS).

-Dave

Re: [Cart-users] Re: Some issues with CART and non-compliant servers

[Michael B. <mbr...@ch...>]

> Okay... which RETS server are you using?  They are terribly sloppy, and 
> should not be allowed to use the word "RETS" when describing their 
> product.
> 
> -Dave

This is too true. Can CRT or someone else have those that are not
compliant remove anything saying they are? 
ARIS, our MLS provider here, makes that claim on their site as well as
verbally, but when I would call to get the login URL, they said there
wasn't one. Hmmmm.

So my plans to make my own client app for my linux box have considerably
slowed down. Besides, even if we did have a RETS server, I need to spend
my time selling real estate...gotta feed the family, you know.

Instead of making noise to the vendor, I'm trying to get onto the MLS
committee with the intent to get the contract awarded to a real vendor
when the contract comes up for renewal again. 

-Michael

Re: [Cart-users] Re: Some issues with CART and non-compliant servers

[Frank K. <fku...@to...>]

Hi Dave,

Thanks for all your great help.

Frank


On Mon, 2004-11-08 at 10:52, Dave Dribin wrote: 
> On Nov 6, 2004, at 4:51 PM, Frank Kurzawa wrote:
> > 1. SAXParseException: The entity name must immediately follow the '&' 
> > in the entity reference.
> > Some MLS listings end up with ampersands in their data, e.g. in the
> > property description. Unfortunately, SAX just throws up over these.
> 
> This is bad... really bad.

That reflects my initial sentiment as well. But since the Avantia client
didn't have a problem with this, I I've been willing to entertain the
idea that perhaps the problem was me. LOL


> > I've not much experience with tweaking SAX, but the only obvious way 
> > that I
> > see to deal with this is to modify the characters() method in the
> > SearchResultHandler to escape any ampersands in the <DATA> content.
> 
> 'Tis too late by the point characters() is called, I imagine.

I'm not too sure that it's too late: I was able to put debug statements
in the characters routine and display the content. So SAX had not thrown
up yet. I think since the ampersand is in the content rather than the
tag, SAX hasn't looked very closely at it yet. (just speculating...)

> > 	Is there a better approach?
> 
> The best method is to yell at your MLS.  The SAX parsers I've seen are 
> not that lenient on XML (and they shouldn't be).  AFAIK, there's no SAX 
> compliant XML parser that will allow ampersands to be legal.  You see, 
> software outside of real estate tend to follow their specifications. :) 
>   A SAX parser wouldn't be an XML parser if it allowed ampersands.
> 
> I suppose one way around this is to wrap the XML input stream and 
> replace ampersands *before* it gets to the XML parser, thus making sure 
> the data is XML before it hits SAX.  But as this has got to be a 
> performance hit, I'd say this is not something that RETS client should 
> do by default, if at all.
> 
> > 2. client.LogoutResponse - Invalid logout response key: Logged Out -> 
> > <null>
> > a.   Actually, I couldn't even get this output until I first modified
> > KeyValueResponse.HandleRetsResponse(). The method assumes that the
> > RetsResponse Element actually has a "=" in the content. If the "=" is
> > missing then a catastrophic null pointer exception occurs.
> > I fixed this by modifying the HandleRetsResponse() method to substitute
> > the string "<null>" if there is no equals.
> 
> Just so I know exactly what you are talking about, what is the full 
> response you are getting from your server here (cut and paste it, if 
> you can)?
> 
0000   00 0a e6 80 6e 5c 00 0c 41 7b e3 ce 08 00 45 00  ....n\..A{....E.
0010   00 82 c1 b1 40 00 6f 06 f3 38 41 53 53 30 c0 a8  ....@.o..8ASS0..
0020   01 60 00 50 81 c7 00 84 87 32 20 d3 55 05 80 19  .`.P.....2 .U...
0030   ff 37 e6 55 00 00 01 01 08 0a 00 06 b7 e6 00 05  .7.U............
0040   67 f7 3c 52 45 54 53 20 52 65 70 6c 79 43 6f 64  g.<RETS ReplyCod
0050   65 3d 22 30 22 20 52 65 70 6c 79 54 65 78 74 3d  e="0" ReplyText=
0060   22 4f 70 65 72 61 74 69 6f 6e 20 53 75 63 63 65  "Operation Succe
0070   73 73 66 75 6c 22 3e 0d 0a 4c 6f 67 67 65 64 20  ssful">..Logged 
0080   4f 75 74 0d 0a 3c 2f 52 45 54 53 3e 0d 0a 0d 0a  Out..</RETS>....
0090  


> > b.   Beyond that, if the server returns anything other than
> > "ConnectTime", "Billing", or "SignOffMessage", then
> > LogoutResponse.handleKeyValue() chooses to fail catastrophically, which
> > locks CART out of the ability to work with some RETS servers.
> > I handled this by modifying the handleKeyValue() method to simply log 
> > an
> > error in this situation.
> 
> The stuff I checked in Friday should handle this.
> 
> > Are my chosen modifications the best way to handle these issues? I'm
> > starting to feel like I need to continually tweak rets-client every 
> > time
> > I work with another (non-compliant) RETS server out there.
> 
> Okay... which RETS server are you using?  They are terribly sloppy, and 
> should not be allowed to use the word "RETS" when describing their 
> product.
> 
> -Dave
> 
> 
> 
> --
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Cart-users mailing list
> Car...@li...
> https://lists.sourceforge.net/lists/listinfo/cart-users


-- 

Frank Kurzawa <fku...@to...>

Topaz Software, Inc.

[Cart-users] Re: Some issues with CART and non-compliant servers

[Dave D. <dr...@cr...>]

On Nov 6, 2004, at 4:51 PM, Frank Kurzawa wrote:
> 1. SAXParseException: The entity name must immediately follow the '&' 
> in the entity reference.
> Some MLS listings end up with ampersands in their data, e.g. in the
> property description. Unfortunately, SAX just throws up over these.

This is bad... really bad.

> I've not much experience with tweaking SAX, but the only obvious way 
> that I
> see to deal with this is to modify the characters() method in the
> SearchResultHandler to escape any ampersands in the <DATA> content.

'Tis too late by the point characters() is called, I imagine.

> 	Is there a better approach?

The best method is to yell at your MLS.  The SAX parsers I've seen are 
not that lenient on XML (and they shouldn't be).  AFAIK, there's no SAX 
compliant XML parser that will allow ampersands to be legal.  You see, 
software outside of real estate tend to follow their specifications. :) 
  A SAX parser wouldn't be an XML parser if it allowed ampersands.

I suppose one way around this is to wrap the XML input stream and 
replace ampersands *before* it gets to the XML parser, thus making sure 
the data is XML before it hits SAX.  But as this has got to be a 
performance hit, I'd say this is not something that RETS client should 
do by default, if at all.

> 2. client.LogoutResponse - Invalid logout response key: Logged Out -> 
> <null>
> a.   Actually, I couldn't even get this output until I first modified
> KeyValueResponse.HandleRetsResponse(). The method assumes that the
> RetsResponse Element actually has a "=" in the content. If the "=" is
> missing then a catastrophic null pointer exception occurs.
> I fixed this by modifying the HandleRetsResponse() method to substitute
> the string "<null>" if there is no equals.

Just so I know exactly what you are talking about, what is the full 
response you are getting from your server here (cut and paste it, if 
you can)?

> b.   Beyond that, if the server returns anything other than
> "ConnectTime", "Billing", or "SignOffMessage", then
> LogoutResponse.handleKeyValue() chooses to fail catastrophically, which
> locks CART out of the ability to work with some RETS servers.
> I handled this by modifying the handleKeyValue() method to simply log 
> an
> error in this situation.

The stuff I checked in Friday should handle this.

> Are my chosen modifications the best way to handle these issues? I'm
> starting to feel like I need to continually tweak rets-client every 
> time
> I work with another (non-compliant) RETS server out there.

Okay... which RETS server are you using?  They are terribly sloppy, and 
should not be allowed to use the word "RETS" when describing their 
product.

-Dave

[Cart-users] Re: Some issues with CART and non-compliant servers

[John R. <joh...@gm...>]

In our (at Threewide) experience, Frank, we have to take into account
differences between every RETS server.  Some of them we handle by
providing a custom HttpClient to the rets-client library.  Other
inconsistencies we have had to handle in the rets-client codebase
itself.  Other problems have been insurmountable to date from the
client point of view.  RETS is still in a early stage, in the while
server vendors have adopted it, clients are only beginning to become
more popular at this time.  Some issues will only be worked out as
server vendor compliance becomes more useful.

As far as your specific fixes to rets-client to work around these
server issues, I would follow Dave's recommendation from another email
(referring to the strict vs lenient login handling), which is: notify
the vendor if they appear to not be following the specification.  That
will help vendors improve compliance, and hopefully soon we will be
able to use a rets-client library out of the box without any
modifications for any compliant server.

John


On 06 Nov 2004 16:51:30 -0600, Frank Kurzawa <fku...@to...> wrote:
> Hi:
> I've had to code around several issues with non-compliant RETS servers.
> Some of these issues may be suitably addressed by modifying CART. For
> others, there may be ways that I can configure CART to handle more
> gracefully. Please give me input on how best to handle these:
> 
> 1. SAXParseException: The entity name must immediately follow the '&' in the entity reference.
> Some MLS listings end up with ampersands in their data, e.g. in the
> property description. Unfortunately, SAX just throws up over these. I've
> not much experience with tweaking SAX, but the only obvious way that I
> see to deal with this is to modify the characters() method in the
> SearchResultHandler to escape any ampersands in the <DATA> content.
>         Is there a better approach?
> 
> 2. client.LogoutResponse - Invalid logout response key: Logged Out -> <null>
> a.   Actually, I couldn't even get this output until I first modified
> KeyValueResponse.HandleRetsResponse(). The method assumes that the
> RetsResponse Element actually has a "=" in the content. If the "=" is
> missing then a catastrophic null pointer exception occurs.
> I fixed this by modifying the HandleRetsResponse() method to substitute
> the string "<null>" if there is no equals.
> b.   Beyond that, if the server returns anything other than
> "ConnectTime", "Billing", or "SignOffMessage", then
> LogoutResponse.handleKeyValue() chooses to fail catastrophically, which
> locks CART out of the ability to work with some RETS servers.
> I handled this by modifying the handleKeyValue() method to simply log an
> error in this situation.
> 
> Are my chosen modifications the best way to handle these issues? I'm
> starting to feel like I need to continually tweak rets-client every time
> I work with another (non-compliant) RETS server out there.
> 
> Regards,
> 
> Frank
> 
> 


-- 

John Rayburn
Manager of Technical Services
Threewide Corporation
w: 304.594.8081
e: jra...@th...
It's all about the data!

[Cart-users] Some issues with CART and non-compliant servers

[Frank K. <fku...@to...>]

Hi:
I've had to code around several issues with non-compliant RETS servers.
Some of these issues may be suitably addressed by modifying CART. For
others, there may be ways that I can configure CART to handle more
gracefully. Please give me input on how best to handle these:

1. SAXParseException: The entity name must immediately follow the '&' in the entity reference.
Some MLS listings end up with ampersands in their data, e.g. in the
property description. Unfortunately, SAX just throws up over these. I've
not much experience with tweaking SAX, but the only obvious way that I
see to deal with this is to modify the characters() method in the
SearchResultHandler to escape any ampersands in the <DATA> content.
	Is there a better approach?

2. client.LogoutResponse - Invalid logout response key: Logged Out -> <null>
a.   Actually, I couldn't even get this output until I first modified
KeyValueResponse.HandleRetsResponse(). The method assumes that the
RetsResponse Element actually has a "=" in the content. If the "=" is
missing then a catastrophic null pointer exception occurs.
I fixed this by modifying the HandleRetsResponse() method to substitute
the string "<null>" if there is no equals.
b.   Beyond that, if the server returns anything other than 
"ConnectTime", "Billing", or "SignOffMessage", then
LogoutResponse.handleKeyValue() chooses to fail catastrophically, which
locks CART out of the ability to work with some RETS servers.
I handled this by modifying the handleKeyValue() method to simply log an
error in this situation.

Are my chosen modifications the best way to handle these issues? I'm
starting to feel like I need to continually tweak rets-client every time
I work with another (non-compliant) RETS server out there.

Regards,

Frank

Re: [Cart-users] Capitalization problems in capabilities url's

[John R. <joh...@gm...>]

This change is currently proposed as a change to the library (I don't
think there is a list of proposed changes out there publicly at this
time).

Dave Dribin - is this change something that we are going to put into
the next minor version release?  It was one of the patches sent by
John Sirois.

John


On 29 Oct 2004 17:23:11 -0500, Frank Kurzawa <fku...@to...> wrote:
> I've just started using the rets-client library in CART.
> 
> Cart is very specific about what keys it will accept for capability
> URL's such as GetMetaData. In particular it only accepts those
> camel-caps, not ALL CAPS such as GETMETADATA.
> 
> I believe that's completely consistent with the RETS spec, but there are
> a variety of supposedly RETS-compliant servers out there that return the
> keys for capability url's in all caps. When rets-client gets such a key
> during the log-in sequence it chooses to fail the log-in.
> 
> Is there a simple way to handle this in a more graceful manner with
> rets-client? I understand there are provisions to in rets-client to
> allow for the inevitable idiosynchrasies in different "more-or-less"
> compliant RETS servers but it's not at all clear to me how to take
> advantage of those capabilities in rets-client.
> 
> Thanks in advance,
> 
> --
> Frank Kurzawa <fku...@to...>
> Topaz Software, Inc.
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Cart-users mailing list
> Car...@li...
> https://lists.sourceforge.net/lists/listinfo/cart-users
> 


-- 

John Rayburn
Manager of Technical Services
Threewide Corporation
w: 304.594.8081
e: jra...@th...
It's all about the data!

[Cart-users] Capitalization problems in capabilities url's

[Frank K. <fku...@to...>]

I've just started using the rets-client library in CART.

Cart is very specific about what keys it will accept for capability
URL's such as GetMetaData. In particular it only accepts those
camel-caps, not ALL CAPS such as GETMETADATA. 

I believe that's completely consistent with the RETS spec, but there are
a variety of supposedly RETS-compliant servers out there that return the
keys for capability url's in all caps. When rets-client gets such a key
during the log-in sequence it chooses to fail the log-in.

Is there a simple way to handle this in a more graceful manner with
rets-client? I understand there are provisions to in rets-client to
allow for the inevitable idiosynchrasies in different "more-or-less"
compliant RETS servers but it's not at all clear to me how to take
advantage of those capabilities in rets-client.

Thanks in advance,


-- 
Frank Kurzawa <fku...@to...>
Topaz Software, Inc.