> I was
 > told by the project manager that Apache, Java, and Tomcat were "showing
 > signs of age."
-- Taking this statement at face value, and taking it to its logical end 
(that you'll have to migrate your application), I'm extremely doubtful 
that Apache, Java, and Tomcat are so near their ends of life that you 
must redo your app in less than 8 weeks time or risk technological 
obsolescence.  Far, far from it.  "Showing signs of age" is just saying 
their old (both Apache and Tomcat had support releases in April), not 
that they don't work or fit your precise needs.  In any event, if the 
timeline is real, then something's not right with the reason for 
changing everything over to "something else" or the person pushing this 
or....  It's a little mind-boggling.

But, to make this a little more constructive, and assuming the 8 week 
deadline is real, I might consider something like MarkLogic given what 
you've outlined thus far [1].  That might allow you to preserve your 
XQuery/XSLT (providing that you have some since you are using eXist) and 
it gets you a replacement for Solr.  Being an XML database and 
application server, it is designed for XML documents.  Unfortunately, it 
is closed-source, but the company offers a "free" license option that 
might work for you.

If you are investigating something with PHP, Python, or Ruby, I would 
look at the Zorba XQuery processor [2], which has bindings for those 
three languages (and a few more) and, being a specific language for 
manipulating XML documents, should be more conducive to what you need to 
do with your files.  It's pure bonus if you can re-use your XQuery. 
There also appears to be some support for XSLT 1.0 [3].  I've not done 
anything with Zorba but install it on a dare.

Cordially,

Kevin

[1] http://community.marklogic.com/
[2] http://www.zorba-xquery.com/html/index
[3] http://www.zorba-xquery.com/html/modules/zorba/programming/xslt




On 05/08/2012 10:17 AM, Ethan Gruber wrote:
> Thanks.  I have been working on a system that allows editing of RDF in web
> forms, creating linked data connections in the background, publishing to
> eXist and Solr for dissemination, and will eventually integrate operation
> with an RDF triplestore/SPARQL, all with Tomcat apps.  I'm not sure it is
> possible to create, manage, and deliver our content with node.js, but I was
> told by the project manager that Apache, Java, and Tomcat were "showing
> signs of age."  I'm not so sure about this considering the prevalence of
> Tomcat apps both in libraries and industry.  I happen to be very fond of
> Solr, and it seems very risky to start over in node.js, especially since I
> can't be certain the end product will succeed.  I prefer to err on the side
> of stability.
>
> If anyone has other thoughts about the future of Tomcat applications in the
> library, or more broadly cultural heritage informatics, feel free to jump
> in.  Our data is exclusively XML, so LAMP/Rails aren't really options.
>
> Ethan
>
> On Tue, May 8, 2012 at 10:03 AM, Nate Vack<[log in to unmask]>  wrote:
>
>> On Mon, May 7, 2012 at 10:17 PM, Ethan Gruber<[log in to unmask]>  wrote:
>>
>>> It was recently suggested to me that a project I am working on may adopt
>>> node.js for its architecture (well, be completely re-written for
>> node.js).
>>> I don't know anything about node.js, and have only heard of it in some
>>> passing discussions on the list.  I'd like to know if anyone on code4lib
>>> has experience developing in this platform, and what their thoughts are
>> on
>>> it, positive or negative.
>>
>> I've only played a little bit, but my take is: you'll have more parts
>> to build than with other systems. If you need persistent connections,
>> it's gonna be neat; if you don't, it's probably not worth the bother.
>>
>> The Peepcode screencasts on Node:
>>
>> https://peepcode.com/screencasts/node
>>
>> are probably worth your time and money.
>>
>> -n
>>