Tags:
create new tag
, view all tags

TWiki Roadmap - Extended

This is a more detailed Roadmap, a result of a brainstorming session of some participants at the Berlin summit. Please comment/refactor as appropriate...

User Experience and User Interface

This topic is intentionally at the top. Work on the interface (in the broad sense, as User Experience, supporting workflow, etc) is priority and should drive TWiki development, no longer the way around. This is our chance to let go of current limits.

  • Establish a vision for TWikis UE/UI - TWikiUserExperienceVision
    • What shall TWiki enable you to do / archieve? What does it mean for it's interface(s)
    • Clarify what we mean when we talk about user interface(s)? - view, edit attach / perl module and the documentation within etc?
      • make the interface(s) capeable of addressing different needs
    • Ensure old users are not left alone
      • Provide a working PatternSkin for those
      • Dont force them to change their behaviour
  • Establish Guidelines - eg. UsabilityCategoriesAndHeuristics
    • Allow and enable people to act independently - based on these guidelines
    • create skins that work out of the box/after upgrade
    • -skin API -
      • One of the simplest ways to have a 'SKIN API' is to create lightweight skins like MoveableTypeSkin, and then focus on making the default skin components that we all share as strong as possible. - SD
  • Set up a UserExperienceTaskTeam and Identify and offer work products
    • offer these work products to the community
    • attract the best person for the job
    • help people who are interested to help but who are not that familiar with UE concepts up to speed by pointing them to good resources.
    • let people work freely on these products following the TWikiUserExperienceGuidelines
    • Task team is responsible for driving TWikis UE
    • work out how to create a UE that reduces the amount of commentplugin based mess, and increases refactoring changes into the 'main' texts

Performance & scalability:

  • Add a new storage system
    • Optimized for
      • Text search
      • ACL search
      • Form-Field search
      • Storage back-end that scales to gazillions of pages with compatibility and audit trail
      • Fast structured queries
      • Address high traffic bottlenecks by e.g. implementing caching
    • Use text files as a authoritive source
    • Generate optimized date for text, ACL, Form field search out of them on request (by admin)
    • Abstract layer for ACLs to be able to use plugins to extend calculation/evalaluation
  • TopicObjectModel
  • TWikiStandAlone
    • Optimze the core for not being constructed on each click/request
    • One approch is to use mod_perl driven development
    • Use the core like a "http-server" handles requests

Application platform:

  • Apps Web
    • Easy to share applications
    • Topic based
    • Multi topic based
    • Topic and extensions based
    • Easy ways to build & exchange applications & components
  • To build this, we need to start from documentation

Integration

-- Contributors: The TWikiCommunity

Discussion

I'm liking very much the directions TWiki is getting! smile

Doubts: What does "One approach is to use mod_perl driven development" and "Use the core like a "http-server" handles requests" mean? I hope to write down my ideas of further TWikiStandAlone development soon and it does include "Optimize the core for not being constructed on each click/request" (as I already wrote at PersonalRoadmapForGilmarSantosJr). I'm also thinking about memory usage. But before into digging at improvements, I'll work on some benchmark framework (I like to see "how much" a change changes things wink )

-- GilmarSantosJr - 06 Sep 2008

Gilmar, I have about the same roadmap as yours (benchmark and optimization for mod_perl), so maybe we could share the work. If you're looking for help, come on IRC and ask around. I just disagree on your conclusions about mod_perl, but using mod_perl driven development should anyway help your other alternatives, so we should agree on that.

-- OlivierRaginel - 17 Sep 2008

Hi Olivier,

I'm just curious about why you disagree on my conclusions (anyway, which conclusions? :p). Most of time I can't show up at TWikiIRC. I'm finishing the work on TWikiStandAlone merge and then I'll write down my new ideas, then we can discuss better wink

If mod_perl driven development means:

  • Not perform the same common tasks for each request
  • Reduce memory usage
I want to go on that direction.

Note: I never developed a mod_perl oriented app before, so I don't know clearly what it really means.

-- GilmarSantosJr - 17 Sep 2008

Hi Gilmar,

Why do you want to reduce memory usage?!

I agree we shouldn't bloat the all thing up like most modern programs do nowadays, but reducing it shouldn't be our focus. We should keep it minimal, but not reduce. How do you want to reduce it if you want to store all common tasks in memory so they can be re-used by further requests?

For mod_perl, there are a few tutorials and books available, but to sum it up I'd say it requires you to split all the business logic into small objects, and deal with the lifetime of each object. Which is anyway what's being done, from what I could see of all the rewrites which were done for 4.2.

I saw that we have too many time difference for TWikiIRC, but I support your proposal: finish the merge, and then we shall discuss. I'll focus on something else for the time being smile

-- OlivierRaginel - 24 Sep 2008

I want to reduce memory usage because "We should keep it minimal" wink I think TWiki uses more memory than it really needs. Example: the topic TWiki.TWikiDocumentation is about 1 MiB, but TWiki uses about 50 MiB to process it. IMHO it's too much memory (consider that you have other users using TWiki at the same time...)

I don't know yet if it's really possible to achieve great reductions (without loss of performance), but I'll experiment some ideas.

Would it be possible to have a 256 MiB dedicated TWiki server to be used by 10 simultaneous users? (if we consider a 2 seconds mean to complete each request, I'm talking about 18.000 requests/hour). Today it seems to be impossible. With DatabaseStore, a thinner prefs mechanism and some other enhancements maybe it wouldn't be that impossible...

-- GilmarSantosJr - 24 Sep 2008

I think there may be opportunities for object persistence between mod_perl runs, but I agree with Gilmar about memory usage. How much of the 50MB is unclaimed garbage is questionable, but the very fact that the allocations are happening suggests it may be doing things stupidly. I'd be interested to see the memory profile of a mod_perl process throughout it's lifetime, especially if you can differentiate used memory usage versus unused.

The Prefs code especially has been irritating me for a long time. It is abysmally inefficient. However every benchmark I have done suggests that it isn't really a major factor in runtime.

-- CrawfordCurrie - 25 Sep 2008

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2008-10-03 - GilmarSantosJr
 
  • 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.