On Tuesday, February 19, 2002, at 06:47 AM, James Bates wrote:
I've just discovered (sorry for being a bit slow on this one ;) ) that CORBA doesn't run over HTTP at all; the HTTP is only used to read a file called db_bootstrap.ior or something that CORBA apparently needs... (I know you guys told me before; I just didn't realize what it meant...)
In view of this, UTF-8 for the HTTP server isn't really necessary, as long as that db_bootstrap.ior thing doesn't need it (unfortunately I don'
t yet have a clue what that file does). I'm thus reverting to the old HTTP server.
Now I did notice that the Xindice.idl file uses "string" everywhere instead of
"wstring" (the IDL wide-character string type). Indeed the CORBA spec states that "string"s are arrays of 8-bit characters (drud...) whereas wstring's are arrays of "wide characters" (what we're looking for really)
This I believe is what breaks the XUpdate, as the call to the CORBA exported
queryDocument() on the Collection interface uses IDL "string"s to store the command. Very likely XPath won't work either with non-ASCII (havent tried yet)
However guess what: when modifying the IDL file and regenerating the Java stubs, these do correctly contain read_wstring() and write_wstring() calls, but the server stub reports an "org.omg.CORBA.BAD_OPERATION: Wchar not supported in IIOP 1.0" exception; no ain't that just great... ! We definately need to get that XML-RPC/SOAP thing going; otherwise I'll be spending more hours debugging CORBA (Not a very appealing prospect I confess...)
Heh, heh, been there done that, came to the same conclusion. I was trying to get wstring working a while back and came to the conclusion that the Sun ORB used by the client is unable to communicate with OpenORB used on the server. If you use OpenORB on the client it works fine, but then you enter another set of problems.
As far as commit access is concerned, I'd much rather you people looked at it
thouroughly first, as the purpose of parts of the code is still not clear to me.
(In particular ValueIndexer.java). I made the patches basically by looking for "suspect" Java constructs (things like getBytes() with 0 parameters), and guessing what to do with them. I am testing myself already. Also, don't forget
these changes can break existing data files.
The point is that you're working on these issues when nobody else was. As long as you're willing to continue on this and work on the details then I'
m still OK with it. This is one of the reasons the changes aren't going into 1.0 and will be part of the next development cycle. We expect things to be a little unstable then and then worked out for 1.1 or whatever the next release is. If you absolutely don't want commit though, then I'll withdraw the request.
Anyway thanks for the positive response anyways :)
Will be back with more on the Apache XML-RPC library later.
James
-----Original Message----- From: Kimbro Staken [mailto:[EMAIL PROTECTED] Sent: 19 February 2002 14:08 To: [EMAIL PROTECTED] Subject: Encoding patch
James,
I just skimmed through your patch. We should definitely look at getting you commit to be able to work on this. I want to hold this until we ship 1. 0 and then we should probably just have you commit your changes directly. There's probably a few things that should be changed and we'll have a lot of testing to do, but on a quick scan it looks good. Tom really needs to review it too though.
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
