jvanzyl 00/10/13 09:26:11
Modified: docs todo.html
Log:
- updated todo.
Revision Changes Path
1.2 +28 -2 jakarta-velocity/docs/todo.html
Index: todo.html
===================================================================
RCS file: /home/cvs/jakarta-velocity/docs/todo.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- todo.html 2000/10/13 01:49:45 1.1
+++ todo.html 2000/10/13 16:26:05 1.2
@@ -141,11 +141,23 @@
object caching/pooling code could be borrowed from Turbine,
JServ, or the Avalon Server Framework.
<P align="justify"></P>
-
+
+ <B>Velocity Profiling</B>
+ <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 align="justify"></P>
+
<B>Encoding Caching</B>
<BR>
What would this entail? And how could we implement an
- efficient encoding mechanism.
+ efficient encoding caching mechanism.
<P align="justify"></P>
<B>Plugins</B>
@@ -208,7 +220,21 @@
How could Velocity be integrated into standard IDEs like
JBuilder and VisualAge?
<P align="justify"></P>
+
+ <B>Scripting Language Integration</B>
+ <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 align="justify"></P>
+
+
</FONT></TD></TR></TABLE></DIV><BR>
