Re: Added new proposal: search feeds
Allen Gilliland wrote: > > > Elias Torres wrote: >> >> Allen Gilliland wrote: >>> Looks fine to me, so +1, but one note. we should be clear about the >>> caching strategy. my expectation is that we would not cache these feeds >>> just like we don't cache search results pages. that would need to be >>> accounted for in the FeedServlet. >> >> It makes sense. It makes so much sense that I'm writing up another >> proposal for complete reverse proxy support (e.g. no page cache at all, >> optionally). >> >> We would like an option that disables page caching in the app server >> because we discovered a large amount of CPU being consumed by >> StringBuffer memory management instead of writing directly to the socket >> stream. > > Sure, I'm always interested in supporting more caching configs =) > > You *can* actually disable all of Roller's rendering caches very easily > in the current code. Each of Roller's caches supports an "enabled" flag > in the config, so if you put ... > > cache.weblogpage.enabled=false > cache.weblogfeed.enabled=false > > in your config file then you don't have caching in the app anymore. i > use this feature regularly in testing. Right on. > > -- Allen > > >> >>> Also, we provide the option for the built-in search to be disable, and >>> that would also need to be handled in the FeedServlet so that search >>> feeds are not returned when search is disabled. >> >> Right. Good catch. >> >> -Elias >> >>> -- Allen >>> >>> >>> Elias Torres wrote: Hi guys (again), Here's another simple/short proposal that I would like comments on so I can get a sense from the community if I can proceed and when. http://cwiki.apache.org/confluence/display/ROLLER/Proposal_SearchFeeds -Elias >
Re: Added new proposal: search feeds
Elias Torres wrote: Allen Gilliland wrote: Looks fine to me, so +1, but one note. we should be clear about the caching strategy. my expectation is that we would not cache these feeds just like we don't cache search results pages. that would need to be accounted for in the FeedServlet. It makes sense. It makes so much sense that I'm writing up another proposal for complete reverse proxy support (e.g. no page cache at all, optionally). We would like an option that disables page caching in the app server because we discovered a large amount of CPU being consumed by StringBuffer memory management instead of writing directly to the socket stream. Sure, I'm always interested in supporting more caching configs =) You *can* actually disable all of Roller's rendering caches very easily in the current code. Each of Roller's caches supports an "enabled" flag in the config, so if you put ... cache.weblogpage.enabled=false cache.weblogfeed.enabled=false in your config file then you don't have caching in the app anymore. i use this feature regularly in testing. -- Allen Also, we provide the option for the built-in search to be disable, and that would also need to be handled in the FeedServlet so that search feeds are not returned when search is disabled. Right. Good catch. -Elias -- Allen Elias Torres wrote: Hi guys (again), Here's another simple/short proposal that I would like comments on so I can get a sense from the community if I can proceed and when. http://cwiki.apache.org/confluence/display/ROLLER/Proposal_SearchFeeds -Elias
Re: Added new proposal: search feeds
Allen Gilliland wrote: > Looks fine to me, so +1, but one note. we should be clear about the > caching strategy. my expectation is that we would not cache these feeds > just like we don't cache search results pages. that would need to be > accounted for in the FeedServlet. It makes sense. It makes so much sense that I'm writing up another proposal for complete reverse proxy support (e.g. no page cache at all, optionally). We would like an option that disables page caching in the app server because we discovered a large amount of CPU being consumed by StringBuffer memory management instead of writing directly to the socket stream. > > Also, we provide the option for the built-in search to be disable, and > that would also need to be handled in the FeedServlet so that search > feeds are not returned when search is disabled. Right. Good catch. -Elias > > -- Allen > > > Elias Torres wrote: >> Hi guys (again), >> >> Here's another simple/short proposal that I would like comments on so I >> can get a sense from the community if I can proceed and when. >> >> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_SearchFeeds >> >> -Elias >
Re: Added new proposal: search feeds
Looks fine to me, so +1, but one note. we should be clear about the caching strategy. my expectation is that we would not cache these feeds just like we don't cache search results pages. that would need to be accounted for in the FeedServlet. Also, we provide the option for the built-in search to be disable, and that would also need to be handled in the FeedServlet so that search feeds are not returned when search is disabled. -- Allen Elias Torres wrote: Hi guys (again), Here's another simple/short proposal that I would like comments on so I can get a sense from the community if I can proceed and when. http://cwiki.apache.org/confluence/display/ROLLER/Proposal_SearchFeeds -Elias
Re: Added new proposal: search feeds
We can. It's just more elements in the template. However, I don't have a design (plan) to implement the discovery-like document for search endpoints and their URI templates. -Elias James M Snell wrote: > Just to be clear: do you intend to include the OpenSearch v1.1 metadata > elements in the search feed? > > - James > > Elias Torres wrote: >> Hi guys (again), >> >> Here's another simple/short proposal that I would like comments on so I >> can get a sense from the community if I can proceed and when. >> >> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_SearchFeeds >> >> -Elias >> >
Re: Added new proposal: search feeds
Just to be clear: do you intend to include the OpenSearch v1.1 metadata elements in the search feed? - James Elias Torres wrote: > Hi guys (again), > > Here's another simple/short proposal that I would like comments on so I > can get a sense from the community if I can proceed and when. > > http://cwiki.apache.org/confluence/display/ROLLER/Proposal_SearchFeeds > > -Elias >
