Re: [Phpwebsite-developers] New version and Roadmap [long]

[Todd O. <to...@da...>]

Yes there will be a rewrite, and no it has not begun yet (at least any
coding).  This mailing list is the official forum to discuss details of the
rewrite.  Over the past several weeks you can see our discussions, which
have dealt mainly with changes to the architecture.  phpWS was built from a
phpNuke core; phpWS(II) will be conceptually different.

The next step for phpWS(II) is to submit a very detailed architectural plan
for everyone to review.  Once the rev2 Roadmap is "approved" by the
developers, then we'll split into teams to begin coding.  The final section
of Brian's Roadmap "Development Team Organization/Management" details this
process well.

I am preparing a software engineering plan for review, but I'm stuck on two
issues.  One of my design goals is to allow a single phpWS installation to
support multiple organizations (500 organizational units [OUs] lets say)
without separate database tables sets.  My original design was a very
structured tree with a branch for each OU; this worked great until I added
the goal of allowing (even encouraging) members of the different OUs to
collaborate on common projects.  Now leaves farther down in the tree
structure (members) have a relationship with leaves in adjacent branches.
Now we don't have a tree, but a mesh!  How do you provide authentication and
control ownership and permissions in this situation?  (I'm working on this
now)

Secondly, how do I allow multiple databases (lets say with 500 OUs each) to
talk with one another for collaboration across database boundries?  I
believe spending the design time to create a distributed scheme will pay off
immeasurably as the project scales.

Many of you may think this is overkill for what you want phpWS to do.  If
you only want to host a single OU, then you don't need this extra
architecture--granted.  The point is that many developers want this
flexibility, which is not available in ANY content management system that I
know about.  I believe this feature will attract many additional developers
in the future, which will improve ALL areas of phpWS.

Right now I don't want to start coding phpWS(II) without thoroughly
considering these design goals.  The code for these "scalability" features
may be written after the rest of the phpWS core, but we don't want to
redesign the core again to add them.  *_It's the difference between a web
SITE and a web application development enviroment._*  Contrary to what many
may be thinking now, I do not believe these design goals will add much
complexity to the project (possibly an additional abstraction layer).

Some perspective:
Last May I met the two high school students that wrote Squirrelmail at the
International Conference on Computing and Missions (iccm.org).  We joked
about how it came to be named after a squirrel, etc.  They wrote the
software for a small missions agency to give a web based alternative to
POP3.  They GPL'd the code and even entered it in ICCM's "Best practices for
missions technologies" where they placed fifth out of five.  If anyone would
have told them or me in May 2000 that Squirrelmail would ever be the number
one PHP web mail product, we would have laughed.  Now Squirrelmail is being
integrated into almost every php portal project around, like phpGroupWare.
They're getting press coverage in many web journals and have an incredible
developer community.

My point is that phpWebSite will be even more successful than Squirrelmail,
if we work hard to produce a project with good architecture and solid code.
In contrast to the constant hacks on phpNuke to add and change
functionality.

Enough pep talk for now.  I'm sure none of you can tell how excited I am
about phpWebSite's ongoing development ;-)

--Todd Owen