[kforge-dev] Some thoughts on areas to focus on

[Rufus Pollock]

0. Integrate recent updates to domain model

Over last few months quite a lot of work has been done on domainmodel 
and there has been a bit of 'open water' arising between it and kforge. 
John and I plan together to get together in the next few days to sort 
this out.


1. Improve install process

This is probably the major priority at present given user feedback. I've 
created a ticket on this at:

<http://p.knowledgeforge.net/kforge/trac/ticket/41>

I've already started on work on this by converting kforge to use setuptools.


2. Convert from sqlobject to sqlalchemy (just a mapping layer)

   * could also use elixir (<http://elixir.ematia.de/>) to help with 
domain object modelling

SQLAlchemy is rapidly replacing SQLObject as the ORM of choice. Slightly 
more restricted than SQLObject in that it doesn't try to do any domain 
object stuff but what it does it does better and more powerfully.


3. Using python eggs and entry points for our plugin stuff:

   * http://base-art.net/Articles/64/

This would suit our current plugin system perfectly and would allow us 
to have plugins which are outside of the kforge.plugin package.


4. Move away from doing access control at the http (apache) level.

Doing access control at that level is just too crude. Instead focus on 
authentication and for access control leave authorization/access control 
to subsystem applications and just do whatever (usually limited) 
integration with the subsystem applications (for example, on project 
create we automatically create trac admin from project admins).