Re: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp

[James Berry <jb...@apache.org>]

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: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

RE: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp

[Scott Cantor <ca...@osu.edu>]

> Well, then, at least we'll say that I can help affect what happens on
> the MacPorts end, since I'm involved with that project ;)

Oh, thanks in advance then. ;-) That would address a lot of my concern,
changing the default is just a means to that end.

I'm going to preparing portfiles for all my components I the next week or
two, so if you'd like I could send a pointer to a 2.8.0 CF-free portfile
when I'm done with it.

-- Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp

[James Berry <jb...@apache.org>]

On Mar 2, 2008, at 11:29 AM, Scott Cantor wrote:

>> For me, it causes a lot of trouble, so it's in my interest to  
>> address that.
> I have to support a half-dozen platforms and anything that makes  
> that harder
> is a negative for me. In particular, I have a serious problem if  
> somebody
> upstream like Macports uses the CF calls in their build instructions.
> Anything I can do to prevent that is time well spent for me.

Well, then, at least we'll say that I can help affect what happens on  
the MacPorts end, since I'm involved with that project ;)

James

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

RE: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp

[Scott Cantor <ca...@osu.edu>]

> Well, I would argue that for (what I would guess are) most xerces use
> cases, the CF transcoder works just fine.

But they don't for mine, and I'm the one stuck dealing with that, so I'm
just voicing my opinion. As I said, I'm basically "voting" and if there's no
vote or others disagree, so be it.

For me, it causes a lot of trouble, so it's in my interest to address that.
I have to support a half-dozen platforms and anything that makes that harder
is a negative for me. In particular, I have a serious problem if somebody
upstream like Macports uses the CF calls in their build instructions.
Anything I can do to prevent that is time well spent for me.

> 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?

Clearly? I wouldn't say that. But regardless, since fork is a pretty
standard function, I wold claim that APIs that don't support it are in fact
broken. Again, just MHO.
 
-- Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org