[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!