Time to bump this thread a bit ;)
Andy Postnikov wrote:
Again and again... A lot of thoughts about ways but what are we talking about?
Proposal to rewrite? What is a target? new features, speed and new bugs...
Ok, here are some ideas I've been thinking about, most of them are based
on what Ryan outlined in the roadmap email
This is a selection of features which pp desperately needs:
* Events framework
o To allow developers to interact with PP at specific
intervals without having to hack the core / other components
* Modular separation of code
o To enable developers to package code as 'modules' so that
they can reuse their code / share it with other developers
* Organised file structure
o Files should be separated into their respective groups i.e. -
System
Helpers
Libs
Application
Controllers
Libraries
Vendors
....
Modules
....
....
etc.
o Allows for overloading of core components
* ACL
o Move permissions out of the models and into a library /
dedicated model, current implementation is too spread out
o Should allow permissions to be added dynamically
* Unit tests
o Allows developers to see if changes they make break the core
* Project Config
o Mainly for 'system' use, would allow developers to control
config on a per project basis
* CACHING!!
o PP is currently terrible at caching - it only caches objects
for the duration of a request.
And here is one that I feel would be beneficial (but not 'necessary' for
the project)
* "Friendly urls"
o Would allow emulation of basecamp api, which would allow pp
to integrate with many products such as beanstalk,
freshbooks etc.
o Tim has made a friendly urls patch which does part of this -
it translates {project_id}/{controller}/{action}?{params} to
index.php?c={controller....., although parameters are still
passed through a query string
At this point, I try to assess the decision using a few questions:
1) What does this gain/provide us with? or what problem does this solve?
2) What does this restrict or lose us? also, What does this cost?
3) Are there any other ways of achieving this? and their related merits.
4) Is this in the best interest of the community/project? and is this
what the community wants?
First of all...
1) It brings a lot of new bugs. Solve some old problems but ...
2) loose compabillity, restrict in support older versions, brings a
lost of old customers and hard way of invit new. Cost is not cheep but
suppose very high!
3) Many ways...
- but first to document current code some way...
- then draw architecture and bottlenecks
- review code (mostly done)
- and only then make proposals! and costs :)
4) What purpose of Community? Bring bugreports & patches, answer a
support questions, collect opinions of features
1. We write the code, we know what's going on and why. We will be
able to fix a number of current problems (timezone support springs
to mind)
2. We lose backward compatibility with previous versions, then again
we can't keep supporting old versions forever else we will never
progress. It would obviously require time to rewrite the entire
project, however it's not as if we are currently using that time
to develop pp as a team
3. Yes, there are two:
1. Refactor the current codebase
1. We keep our 'identity' as a standalone application and
have no dependencies on third party apps (barring
vendor libraries)
2. All the core functionality is present (i.e. tasks,
milestones), we just need to make it extensible
3. However, if we make a change we have no idea what the
repercussions will be as we don't know what references
it (unless we use a global "find / replace")
2. Rewrite PP
1. We can selectively include / exclude features
2. We "know" the code
4. The "community" want need to be able to customise and extend pp.
At the moment customising involves modifying core files and making
sure you carry over the edits when you upgrade. If we asked the
community "Shall we rewrite PP" I imagine most wouldn't mind too
much - They just want something that works, but don't really care
how as long as they can upgrade easily. Those who have hired
developers / invested time to customise their current
installations will be a little peeved at the concept of having to
recode all their modifications to work with a rewrite, although
I'm sure they will be able to see the possible benefits of
upgrading. Finally, there will be others who think that we should
stick with the current codebase. The main purpose of the
community is to test PP, submit feature / bug reports and if they
are able to, patches.
Alex
side note - @Ryan, shouldn't the 3rd party libraries be svn:externals so
that they can be kept up to date easily?
--
Usually something witty would go here, but as I'm the sort of guy who doesn't
have a catch phrase I'm afraid this is nothing but more than ultra boring
rubbish - which you've been suckered into reading :P
No virus found in this outgoing message.
Checked by AVG.
Version: 8.0.138 / Virus Database: 270.5.12/1597 - Release Date: 07/08/2008 05:54
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Projectpier-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/projectpier-development
