Tags:
create new tag
, view all tags

Goals for 4.1

My first take on this:

Item Related topics Who wants
Fix as many as possible of the bugs deferred from 4.0.2  
Fix, or at least improve, access control AccessControlLists ML
Get as many plugins working as possible EssentialPluginsAtDakarRelease  
Put more needed stuff into TWiki::Func    
Create base class for object-oriented plugins PluginsShouldBeObjects  
Clean up as many SMELLs as possible. http://blogs.sun.com/roller/page/alanbur?entry=twiki_rant  
Start to think of how to migrate existing TWiki installs to saner architecture    
Make doc sane: Move documentation from TWiki to new web (Docs?); organize docs by user-type, look through Support for common questions and write doc for those    
Clean up/split up Codev    
Implement more more stuff CopyPreviousRevisionTopicContentIntoNewRevision, BetterMore
Improve performance. Fixing ACL will help. Other than that, not a clue    

-- Contributors: MeredithLesly

Discussion

Fixing of bugs should always be a goal. Noone can argue that.

Fixing many plugins that are broken in the 4.X context because of API changes or because the original author used internal functions is essential. There is a lot of value for our users in the plugins. But that is not 4.1.

Cleaning up codev is not 4.1. Make doc sane is just words. more more stuff is sort of words.

What I notice - and this is a general problem in the community - is total ommission of the most essential problem Twiki has. It is too slow out of the box. And as number of topics grows it gets worse. Scalability is a serious issue. Naturally a school girl can use TWiki for her "My Little Pony" site. But TWiki targets the enterprises. TWiki 4 is approx 30-50% slower than Cairo.

We have most of us read Alan Burlison's TWiki Rant in which has this description of our beloved TWiki: TWiki runs like a tranquillised slug at the best of times . Now Alan may be a person that we had preferred participating raising bugs and providing patches instead of ranting but he has a point.

Not so long ago a guy came by #twiki on Freenode IRC and asked where he could find the download for Cairo. When asked why he wanted Cairo and not TWiki4 he answered that he had tried TWiki4 and it ran too slow. So now he wanted to upgrade to the last Cairo instead. Not very encouraging when we think about all the time invested in Dakar/TWiki4 development and testing.

We need to give up the featuritis for a while and pump some performance back into TWiki. We probably both need to get some short term improvements done to make us par with Cairo and longer term revolutions to address scalability. And whatever we do it must be in a way that never jeopardize the value that has been put in all the millions of topics our 1000s of admins and 10000s of users have created over the 6+ years of TWiki.

But for now we should not focus much on more more stuff

Bugfixing, update plugins, improve performance, Improve Wysiwyg. Those are my 4 priorities.

-- KennethLavrsen - 29 Mar 2006

  • skins (yes, i know that's vague)
  • SubversiveStore (should address the issues in DakarDocumentationModelIsBroken)
  • scalability (however, boy it sure would be nice if we had a little help on that front from any of the multitude of companies with huge twiki installations...)
  • speed
  • other stuff as yet undecided (mostly depends on what people decide to work on)

i think twiki 4.0.2 will be a very stable release, so what's next for the 4.0 line? here are my suggestions:

4.0.3 - 4.0.2 + when we have 100% translations (and any bugfixes during that period) plus any speed optimizations that become available

4.0.4+ - continuing bug fixes plus speed optimizations which are being prepped for 4.1

-- WillNorris - 29 Mar 2006

I know from past experience this will be ignored, but the problem with twiki is that it isn't becoming simpler as I suggested, but always MORE complex.

I installed the latest release and am going back to a previous one. All the work I did on templates and styles is broken on new release.

And of course as the complexity increases, so do the complaints as above indicates. I'm not surprised. Anyone comes in without a programmers mentality is ignored on twiki. Therefore instead of a more usable product you have a less usable one, which happens to be a lot slower as well. Too bad. It is an excellent program, simplicity is smart, not stupid.

-- BruceRProchnau - 29 Mar 2006

Ack. Sorry. When I said "more more stuff", I didn't mean vague "let's add features". Poor wording and typography. I meant add "Clone page", "Revert page" (whatever that's going to be called) and such. I've corrected my entry.

And, yes, performance. I agree completely. I just don't have a clue how to figure out why it's so slow and how to improve it, other than (I suspect) changing ACL. And, yes, that means that there will have to be a script to move ACL out of text to accomplish this, because checking ACL by first searching the topic on every single view is crazy.

I know that compatibility is essential, but "compatibility" is a vague term. It is probable that literal compatibility -- never requiring a scripted change to topics, that is -- will inherently imply poor performance. If so, then existing sites will have to chose between retaining old-format topics and performance improvements.

Sometimes "compatibility" means "migration path". New versions of, for example, Microsoft Word often require you to save your documents in the latest format to take advantage of new features and (sometimes) performance improvements. Since editing and saving 1000s of documents manually is impossible, the closest we can come to that is to write the most robust migration scripts we can come up with.

Probably compatibility deserves a discussion of its own, in part because it's a complex issue and in part because it's apparently a controversial issue in the TWiki community.

-- MeredithLesly - 29 Mar 2006

BruceRProchnau, we actually are listening, but we're basically working as hard as we can. making simple (especially with the core code as it is) is not simple, and has required alot of infrastructure to ensure that those people that use the complexity don't also have a problem. We've been walking a fine line, and trying to run with sissors. see FightTheFat, and many other places were we are working on moving features out of the core.

wrt the template changes - eeek - I had kind of assumed that you could still use your old ones, but i've not had time to test this theory myself frown

-- SvenDowideit - 30 Mar 2006

Code complexity and Architectural complexity are different things. CrawfordCurrie has vigorously attacked the Code. The rationalizing of the code to the Obect model has, sadly, prodcued a bloat, and because of the nature of OO with Perl, aditional overhead. But the code is more manageable.

Architectural complexity is another matter. Issues such as

  • flat-files vs Database
  • access control in-band
  • META data in-band
  • handling of verbatim blocks
  • allowing both %TAG% and %TAG{...}%
and of course
  • plugin architecture
all have a significant impact. They also constrain what can be innovated in the coding.

This is quite easy to see when one compares TWiki's code base with other Wiki and Blog - in particluar for rendering:

  • Redcloth - which implements the Textile engine in Ruby The Textile engine is also available in Perl at CPAN. It makes an interesting comparison with TWiki's engine.
  • Bluecloth which implements the Markdown engine in Ruby, This is an alternative ML-to-HTML engine. The Bluecloth home page refers to Instiki, a Ruby based Wiki. While not as capable as TWiki it puts paid to the myth that Ruby is slower than Perl. Why? Because it uses fundamentally different idioms that are in keeping with the language. I recommend trying Instiki.
  • The render chain technique used by KWiki which is stunningly simple. It approaches a "everything is a plugin" approach so plugins are very lightweight.

See, in general http://c2.com/cgi/wiki?CategoryComplexity

-- AntonAylward - 30 Mar 2006

I don't think we can get a "major" gain in speed from "patch" or even "minor" releases. I think that "30% slower than Cairo" it's an architectural barrier.

-- RafaelAlvarez - 30 Mar 2006

Bruce: We are listening. I totally agree that our community is developer centric. The TWiki project could be much more successfull overall if we focus more on the market. The reason why we need Personas to understand the users, a ProcessForMarketDrivenInnovation and a CustomerFocusedTWikiOrg website.

There is a correlation between KISS and usability. We made good improvements on the UI with the PatternSkin, but some other usability enhancements do not get enough attention, or get implemented with a developer centric UI.

One example of doing the right thing: The Jotspot tracker allows one to paste a spreadsheet into the wiki. As a result, from the users perspective you simply see a spreadsheet on a wiki page. And you can edit it in place. The technical details are hidden from the user: Each table row is a separate wiki page (similar to a TWikiForms application). The user does not need to know that detail, and in fact there is not even a link on the table row to go to the wiki page that contains the form data. The whole system has some complexity, but it is designed with users in mind, e.g. it looks really simple to the user.

I think we get a much better TWiki product if the TWikiCommunity thinks more user centric. This is easier said than done. I think Personas help us understand the users better.

On performance, Kenneth described the current situation nicely. I have nothing to add.

-- PeterThoeny - 30 Mar 2006

Kenneth described the situation accurately. The question is, what are we going to do about it?

-- MeredithLesly - 30 Mar 2006

I think that its time to stop thinking in TWiki as a product to satisfy customers. TWiki is a OSS project, people will do only what they need or want to do, nothing else. If someone feels the pain of a (paying) customer because TWiki is slow, he'll go through hell and heaven to try to fix it (see Kenneth. If he knew enough perl I'm sure that by now TWiki would have been a lot faster). But if the same (paying) customer want something else instead of performance, don't expect that developer to do a profiling on the code unless just for the sake of it.

In the same line, if a (paying) customer is satisfied with a "developer-centric" solution, then it'll remain "developer-centric".

And as we all have totally different customer, our needs are totally different. For example, I don't need to improve performance, and my users are all tech-savy developers. All my contribution to TWiki have been driven by their needs, not the needs of Kenneth, Meredith, Crawford, Sven, you or their (your) clients. Except for those that are just for fun (like profiling the code to see why it's slow, or caching the language name to improve speed).

In short, we're a community of volunteer driven by very heterogeneous needs and clients. Sometimes our needs intersec, sometimes they don't. It's utopic to think that we're going to go in the same direction all the time. And more utopic is to think that that direction can be set into stone.

In that light, is time to stop preaching and start acting. The idea of Personas just don't gel (ie, nobody is acting on them), then the best way is to start using them, show their benefits and try to convince people to use it. If some interfaces are too "developer-centric" then it's time to start list them, explain "why" are too developer-centric, perhaps propose some enhancements, and most likely do one or two of the enhancement to make people move.

Bottom lines: Bruno, we listen. It just that we tend to ignore people that describe problems but offer no solution (I'm not implying that's your case, I have no info about it). And that has been the most common case with non-developers joining the comunity. If you go one step further, and actually make suggestions (FeatureRequest in Codev) I assure you that there is a lot more chance that someone will listen to you.

Peter, stop preaching and start acting. It would be useful to have an example of Personas in the TWiki context and how they can help (perhaps describing the process of using those Personas to enhance one specific aspect of TWiki). A list of "developer-centric" features with some suggestions on how to improve them would be nice, too.

Everybody: I know that most of the active developers are too busy trying to have a life and pay the rent. Finding a sponsorship to have them to work in improving TWiki performance would be nice.

-- RafaelAlvarez - 31 Mar 2006

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2006-04-06 - MeredithLesly
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.