jvanzyl 00/10/13 09:24:27
Modified: xdocs todo.xml
Log:
- updated todo.
Revision Changes Path
1.3 +28 -2 jakarta-velocity/xdocs/todo.xml
Index: todo.xml
===================================================================
RCS file: /home/cvs/jakarta-velocity/xdocs/todo.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- todo.xml 2000/10/13 01:47:26 1.2
+++ todo.xml 2000/10/13 16:24:21 1.3
@@ -137,11 +137,23 @@
object caching/pooling code could be borrowed from Turbine,
JServ, or the Avalon Server Framework.
<p/>
-
+
+ <strong>Velocity Profiling</strong>
+ <br/>
+ If someone is handy with one of the standard profilers,
+ it would be great to start hunting for bottlenecks. No
+ serious optimization has been started. But in conjuction
+ with the presence of a JUnit test suite, optimization
+ changes could be made with confidence. It would be nice
+ to have a configuration of a setup for a common profiling
+ so that anyone who wanted to do some profiling could do
+ so in a consistent manner.
+ <p/>
+
<strong>Encoding Caching</strong>
<br/>
What would this entail? And how could we implement an
- efficient encoding mechanism.
+ efficient encoding caching mechanism.
<p/>
<strong>Plugins</strong>
@@ -204,7 +216,21 @@
How could Velocity be integrated into standard IDEs like
JBuilder and VisualAge?
<p/>
+
+ <strong>Scripting Language Integration</strong>
+ <br/>
+ This is something that has been discussed on the Turbine
+ list. Allowing Context building classes to be written
+ in JPython, Rhino or another scripting language. This would
+ dramatically improve development time and might allow technically
+ proficient web designers who are familiar JavaScript to create
+ an entire servlet solution with Velocity. And as most of these
+ scripting solutions provide a compiler, performance would still
+ remain at an acceptable level.
+ <p/>
+
+
</s1>
</body>
