|
Tuesday, November 12, 2002 |
|
I am finally having some success with Zoe's store.objectsWithSpecification method (see Zoe XML-RPC Specification Docs). It appears that the operators "contains" and "like" may not be handled by the Lucene search engine. At any rate, those two operators never return a result for me. On the other hand, both the "equal" and "notEqual" operators do return results. Something is still flaky; I think both the equal and notEqual queries are returning the same set of results. No time to investigate now; my wife has chili waiting on the table. More tomorrow, I hope. 6:09:48 PM 
|
|
I received a message from Garrett just moments ago. I've been trying to do some very basic stuff (Zoe/XML-RPC) in perl, but I'm not having ANY luck at all. I keep getting something like: "Can't connect to localhost:10123 (Timeout)", so I'm wondering if it's the Auth stuff... I was hoping that if I poked through your stuff, I'd see something that explained authentication more... Dang! ;). I think I know the answer and meant to mention it in the original article. Here is my response to Garrett (and others that have had Zoe login problems).
I have not run into that particular error, but I have an idea on where it is happening. Zoe's XML/RPC interface requires a login. That only works if you have configured the login service on Zoe's Preferences page. You can specify any id and password there. Be sure to use the same one in the authorization header of your http packet. |
|
"In teaching someone about COM programming, it would be nice if I could just teach them how to use the Visual Studio wizards and all the code generation features, but if anything goes wrong, they will not have the vaguest idea what happened or how to debug it and recover from it. I'm going to have to teach them all about IUnknown and CLSIDs and ProgIDS and ... oh, the humanity!" [Joel on Software] Another good read from Joel Spolsky. I think another way of looking at this is that software tools make us more efficient, but they do not make us smarter. We appear to be smarter, doing things we maybe could not normally do (e.g. publishing WSDL for web service consumers), but the illusion is shattered when either the tool or the deliverable breaks. Once we have to investigate the break, we are only as smart as the knowledge we have about the underlying process. That can be a humbling, and frustrating, experience. This raises an interesting and controversial question. Given a simple-to-use set of tools (read "good abstractions"), can business clients write software code for commercial transaction processing systems? The answer is "yes". I think the question is wrong, however. A better set of questions is: should business clients write code for commercial transaction processing systems? Do the abstractions make them smarter, or simply more efficient? Does it costs more to fix a broken transaction (opportunity loss plus expense) than it would have to employ a developer to write the software in the first place? That last question assumes a knowledgeable developer, but I think that is fair in this discussion. My gut says that high-volume transaction processing systems on which a corporation is dependent for revenue are systems that must be reliable. From the CEO's perspective, it's not a matter of having easy-to-use abstractions, it's a matter of knowing the abstractions and their limitations. |
