Hey Chris,

"ePrints Support" <[EMAIL PROTECTED]> writes:

> Which Versions of x-c and x-p? We tried a number of combinations.
> 
> It fails with all - Our aim was for the latest stable versions.
> 
> perl on my test machine does not load the pthreads.so and I think
> that's the problem. I could be wrong... The test bin's in the 
> xerces-c work fine, by the way.
> 
This seems like an issue with RedHat 7.1, since I currently run it on
a 6.2 system with no trouble. When you say it *won't* load, I'm not
sure what you mean. Must be perl if the xerces-c samples work. Give me
more details and I'll see what I find out.

A friends giving me an account on a 7.1 box, and I'll try it there. 

> We are seriously considering our own Big Bad install package
> as our system requires about 6 non-default perl libs.
> 
> I'm hoping to abstract the DOM interface a little, so that 
> people wanting to play with our software can just use XML::DOM
> (slow, but easy to install), but people running on a production
> server can run your XML::Xerces DOM.

I think that would be an interesting approach. You could create
typeglob aliases to help. Alias a set of functions in your own
namespace to XML::Xerce::* if they want Xerces, otherwise use
XML::DOM::*. Anyplace where the API's differ from Xerces to XML::DOM,
you could just have a wrapper method delegate appropriately, or give a
warning/error for 'unimplimento'.

> As for your big-bad install, not a bad idea, esp. if you can 
> make it skip swig without resorting to editing the Makefile.PL

This is a must for me. I intend SWIG to be 105% unnecessary for
users. It's only a must for developers who want to modify the core
files and regenerate the interfaces. The issue is that MakeMaker has
gotten soooooooooo..... complicated, it seems to live its own life. I
get Makefile dependancies I can't control.

> All in all we're really hoping to get this working and easy for
> people to install - it looks very promising. I was afraid we might
> have to try and do a minimal perl module in C++ for DOM ourselves.

God forbid.... I hope that Xerces.pm can do it for you.

> Thanks for your help. I've been working hard on the eprints software
> for 6 months now, and the XML::DOM library could be a show-stopper as
> to generate a fairly simple web page it peaks the processor on my
> P3 833.

Wow... That's extreme. The whole reason I would up maintaining Xerces
was because we were using XML::DOM for a scientific DB project, and
when we did some tests on some reasonably big XML files (20Mb),
XML::DOM dove up to 600Mb of memory usage, and slowwwwwwwww. 

Most of the files I've been running through Xerces are much smaller,
though. I'd like to get the IDOM interface working (from Xerces 1.5)
and really test it out. Very low memory footprint, and much better
speed (and handles SMP and multi-threading).

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to