Mailing-List: contact allura-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: allura-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: 76.96.62.32 is neither permitted nor
 denied by domain of dave@brondsema.net)
Message-ID: <52655F37.5060608@brondsema.net>
Date: Mon, 21 Oct 2013 13:07:03 -0400
From: Dave Brondsema <dave@brondsema.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "allura-dev@incubator.apache.org" <allura-dev@incubator.apache.org>
Subject: ideas for caching wiki pages, etc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I'd like to address https://sourceforge.net/p/allura/tickets/6207/ soon.  The
summary is that we currently have a max char size for rendering markdown, since
sometimes it can be extremely slow to render (and we've tried to improve that
with no luck).  A max char size is ugly though and we don't want that.  We added
caching for markdown rendering recently, but have only applied it to comments
("posts") so far.  If we expand it to wiki pages, tickets, etc, then the max
char limit can be removed or made much much higher.  But it's more likely that a
macro (e.g. include another page) will be used in wiki and tickets and then our
simple caching strategy won't work well because the macro won't be re-run.

Anyone have ideas for how to do cache invalidation in that situation?  One idea
I have is pretty crude, but might work: check to see if there are any macros in
the markdown (search '[[') and never cache those.


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><