I've searched the archives, but can't find reference to this (Java NIO, the new I/O routines from 1.4.x). What I'm interested in is integration between Velocity and NIO...

By way of introduction, I implemented something that is almost identical to Velocity (before I knew V existed, honest!), but proprietary, except that output is directly into ByteBuffers (the low-level primitives that NIO uses exclusively), combined with a very simple lazy execution...the static parts of the template are converted (and provided) immediately, whereas all the foreach loops etc are partially converted and stored (in form similar to a standard parse tree) ready for quick execution later on. So, where V has one context, I have two - the "static" and "dynamic". Any expression that can be evaluated without using the dynamic context is eval'd immediately, anything that uses the dynamic one is stored for later (lazy) execution.

The point of all this is to have a templating engine that works very smoothly with NIO, and where as much as possible can go into ByteBuffer's for (hopefully) optimal transmission when needed. I have a very simple keyed caching system that allows parse trees to share the ByteBuffers for any syntactically identical input. (NB: NIO has a method call to do gathering writes, pulling data from a sequence of ByteBuffers)

So, when I came across V recently, I was delighted - I concur heartily with 99% of the design of V...my own system is as I said almost identical (barring syntax), although slightly less feature complete. However, I'd really prefer not to throw away both the easy NIO integration and the lazy execution.

Is there anyone interested in helping me modify V to support these features? I work better with someone to bounce things off :). AFAICS the output to ByteBuffer's is very little work, and should easily fit in with the rest of the API (it would just mean an extra version of things like mergeTemplate that spat out a ByteBuffer), but perhaps the lazy execution would be much harder; I'd appreciate the co-operation of someone who understood the V code much better than I.

I don't know whether/how any of this could/should be merged into V's main code, but I'd like to do so if you felt it was useful. My employers are also happy for me to work on this at work (they're generally supportive of anything under the apache/BSD licenses - and would also prefer us to be using a less proprietary system :)).

Regards.


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



Reply via email to