On Feb 28, 2008, at 9:47 AM, Scott Cantor wrote:
You mean in case the application forks or are there other cases?
I'm not about to conclude that there's only one system call that
prevents
them from being used. I don't take kindly to OS vendors breaking my
code
like that, so that tells me not to use their APIs.
ICU will be used by default now for both transcoder and message
loader
if ICU is present on the machine. I remember somebody saying that ICU
is installed on OS X by default so this should work out ok, right?
It's installed but without headers. You have to use your own ICU.
The one
they include is for Apple use only.
If it will use ICU by default if it's present (meaning the headers I
assume), I think that's good. My opinion is that failing if it's
missing
would be even better. I'd rather have to manually tell the build to
use
broken APIs than have it do so silently.
Hi Scott,
Well, I would argue that for (what I would guess are) most xerces use
cases, the CF transcoder works just fine. The APIs are not "broken",
but they are not designed to be used across fork and clearly warn
about that case when you try to do it. Right?
James
If somebody's packaging it and wants the CF calls, they can
certainly do so.
That's just MHO anyway. Either way, this is an improvement, thanks.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
