|
From: John R. <joh...@gm...> - 2004-11-08 12:47:36
|
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! |