[okfn-help] further to load on us0

Thu Oct 8 16:59:43 BST 2009

Martin Keegan wrote:
> On Thu, 8 Oct 2009, John Bywater wrote:
> 
> Where's the current roadmap?

KForge roadmap is here:
http://knowledgeforge.net/kforge/trac/roadmap

KForge backlog is here:
http://knowledgeforge.net/kforge/trac/report/9

> I don't know what I think KForge should look like. I don't like the look
> of the repeated boilerplate Apache config stanzas, and am wondering how we
> expect it to be deployed (e.g., by an organisation which hosts KForge
> instances on behalf of others?)

Suggestions for changes to the KForge Apache configuration would be very 
welcome. It's generated by walking over the model, and it looks a bit 
messy. I'm sure there's lots of room for improvement.

On the SEM level, there are at least three ways of deploying KForge 
documented in the INSTALL file: a manual route; automatically with 
kforgevirtualenv.py; or even more automatically with Provide.

On the SLM level, there are various scenarios: enterprise LAN/WAN 
maintained by in-house staff; enterprise LAN maintained by application 
service provider; off-site maintained by in-house staff; off-site 
maintained by application service provider.

> 
> Anyway, that's a broader issue. What I want to know right now is how hard
> it is to memoise the result of password lookups into some time-limited
> cache, so we can reduce the number of calls out to postgres.

I was thinking about that earlier. It's access control of authenticated 
sessions, not authentication, that takes time. We need to memoise the 
results of person-action-object tuples. I'll see what I can do.

Jb

> 
> Mk
> 
> 