You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by ge...@apache.org on 2001/04/02 06:07:22 UTC
cvs commit: jakarta-velocity TODO.txt
geirm 01/04/01 21:07:22
Added: . TODO.txt
Log:
just a move of the old TODO-1.0.txt
Revision Changes Path
1.1 jakarta-velocity/TODO.txt
Index: TODO.txt
===================================================================
+------------- Critical For Release -------------+
o UML Diagrams
PLAN:
Use a tool to reverse engineer the code in XMI so we have
something to play with in Argo.
STATUS:
Ilkka Priha has made us a set of XMI files for Velocity,
I will check them into CVS and we can go from there.
[JVZ] I've place the XMI file on the apache website
if anyone wants to take a crack at using ArgoUML.
o Specification Files
PLAN:
1. Update the bnf and ast files to reflect latest Velocity code.
2. Make sure that the questions in the questions file
are all answered and dealt with.
STATUS:
[NONE]
+------------- Not Critical For Release -------------+
o Speed testing suite
PLAN:
Create a repeatable testing suite for Velocity so that it can be
compared against other tools. In other words, other tools should also
be plugged into this suite. We can also use this to test the relevant
performance of changes made to Velocity.
STATUS:
None
o Control Caching Resource Usage
Change resource caching to limit cache size and expire
least-recently-used. This is needed to prevent Vel from
sucking up RAM uncontrollably for content-centric or
other sites that may use #include() or #parse()
extensively.
PLAN:
Fix code.
STATUS:
[GMJ] Punt for next release.
Re: cvs commit: jakarta-velocity TODO.txt
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Daniel Rall wrote:
>
> geirm@apache.org writes:
>
> > o Control Caching Resource Usage
> >
> > Change resource caching to limit cache size and expire
> > least-recently-used. This is needed to prevent Vel from
> > sucking up RAM uncontrollably for content-centric or
> > other sites that may use #include() or #parse()
> > extensively.
> >
> > PLAN:
> > Fix code.
> >
> > STATUS:
> > [GMJ] Punt for next release.
>
> I have an implementation of a Hashtable-based LRU algorithm in Tigris
> <http://helm.tigris.org/source/browse/helm/java/org/tigris/helm/tool/BufferCache.java?rev=1&content-type=text/x-cvsweb-markup>.
>
> This is something that I just made up out of thin air (meaning I
> didn't get the algorithm out of a book, it just came to me one day),
> so if you have some suggestions on improving it I'd love to hear
> them. This implementation is the basis of business object caching in
> Helm.
>
> Thanks, Daniel
Yes, lets take a look when I come to...
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: cvs commit: jakarta-velocity TODO.txt
Posted by Daniel Rall <dl...@collab.net>.
geirm@apache.org writes:
> o Control Caching Resource Usage
>
> Change resource caching to limit cache size and expire
> least-recently-used. This is needed to prevent Vel from
> sucking up RAM uncontrollably for content-centric or
> other sites that may use #include() or #parse()
> extensively.
>
> PLAN:
> Fix code.
>
> STATUS:
> [GMJ] Punt for next release.
I have an implementation of a Hashtable-based LRU algorithm in Tigris
<http://helm.tigris.org/source/browse/helm/java/org/tigris/helm/tool/BufferCache.java?rev=1&content-type=text/x-cvsweb-markup>.
This is something that I just made up out of thin air (meaning I
didn't get the algorithm out of a book, it just came to me one day),
so if you have some suggestions on improving it I'd love to hear
them. This implementation is the basis of business object caching in
Helm.
Thanks, Daniel