TWiki->NG

The steps to a fast, secure, maintainable, reliable Next Gen TWiki:

• Determine the set of functions TWiki is currently (Cairo) supposed to perform.
• Determine exactly how/if those functions are implemented. This is, of course, not possible, but should be attempted anyway.
• Develop a comprehensive reference to the functionality, in the form of diagrams and simple description.
• Develop a comprehensive cross reference and description of a specific version of TWiki.
• Split the development tree into A) the entire current devlopment tree (including the recent Dev vs. Stable split) and B) an entirely separate tree which does not use anything from the current TWiki except the above-mentioned reference to functionality .
• Branch A continues fixing, patching, upgrading as normal.
• Branch B begins design. In my opinion, it should be a thoroughly OO design.
• ... Then some other stuff happens ...
• Once (B) has stable change, testing, design, enhancement and community-communication methodologies (this last should follow what has become the de facto style in the OSS/FS world) and it has a stable implementation, TWiki->NG can be foisted off on the unsuspecting, er... "released to the" World.
• Peter has a breakdown from trying to oversee a minimum of three different project branches, but the World hails TWiki/TWiki->NG as the first real step toward Global Peace and Collaboration.

Did I leave anything out?

-- KevinKinnell - 22 Dec 2004

An OO rewrite can be done. Key goals:

• In line with the TWikiMission and engine compatible with existing content
• Better performance
• Dev model agreed on by the dev community

-- PeterThoeny - 23 Dec 2004

The TWikiMission is what makes and has made TWiki work so well for so long for so many: no question that it has to be the centerpiece. Something I didn't make clear above is that any redesign has to be transparent to the users of any existing TWiki (the admins are a different story) because you do not want to break functional compatibility. That would of course mean that any existing content would have to work; any internal transformations for new models would have to be minimal (preferrably non-existent) and happen on-the-fly (preferrably only once.)

But all of that is moot -- this is just a ramble. One thing I think I will undertake is comprehensive survey/xref of the exisiting code. That's the first step to doing any kind of comprehensive security fix or design change. I'll get with whoever is filling the TWikiArchitectRole and TWikiSpecCoordinatorRole about this.

-- KevinKinnell - 23 Dec 2004

Wow. A name from the past. Welcome back Kevin!

-- MartinCleaver - 23 Dec 2004

Hi Kevin, MichaelSparks sends you a warm Welcome back.

-- MattWilkie - 23 Dec 2004

Aw, shucks. Thanks, y'all.

-- KevinKinnell - 23 Dec 2004

What have you been playing with in the interim? What's brought you back?

-- MartinCleaver - 23 Dec 2004

Kevin, welcome back! you really should take a look at the DevelopBranch - Crawford has been working hard toward making TWiki more viable, including unit testing, automated builds and refactoring it to be more maintainable (OO wise, and simplification wise

-- SvenDowideit - 27 Dec 2004

Evolution rather than revolution; the goals of my work have been refactoring for consolidation, performance and documentation, and the development of a test methodology.

I've been reworking the implementation to clarify and strengthen the architecture, by encapsulating functionality much more strongly. This has involved elimination of all session-specific global variables, and creation of management classes for each function domain e.g. store, users, preferences etc. A singleton is instantiated for each of these classes. I have also developed performance benchmarks and unit tests for several modules, and re-used existing tests (such as there were) in the new framework.

The resultant code should be functionally equivalent to Cairo, except where bugs have been fixed (and there have been several).

-- CrawfordCurrie - 02 Jan 2005

Okay, this is where I would've gone, modulo making sure that the singletons are not singletons by design, but by architectural choice. But that's pretty glib: it's easy to say "this is how it should be done" if you haven't had to do it.

On the other hand, this topic is a ramble, so reality doesn't have to encroach much . I still think that <duck status="ready"> TWiki->NG requires a complete rewrite of TWiki <ducknow /></duck> <response to="onions"> nyah, nyah yah missed me </response>

On a more serious side, the Free Software community, for better or for worse, has developed a set of de facto methods for doing development and communicating with constituent groups; TWiki is a little scary for some organizations because they can't get a quick handle on how the TWiki team will communicate with them in the event of a problem. I'd hate to lose the benefits of the very-collaborative-but-parochial TWiki ways just to get the benefits of the very-regimented-and-widespread FSF/Sourceforge ways, but there must be a way to present that regimented face.

-- KevinKinnell

TWiki has classically suffered from bottlenecking as a result of the imposition of a rigid development methodology which was largely unmanaged and not engaged with by the developers.

The goal of the forms redesign in Codev was to simplify and clarify working practices, reducing dependence on the core team, so that non-core-team developers could engage and strangers could drop in an quickly understand what is going on. Sadly, it's pretty much stalled, waiting for the forms to be enabled.

-- CrawfordCurrie - 04 Jan 2005