-- PeterThoeny - 10 Aug 2002

Some comments on the additions I've put above:

• We tend to use the enhanced definition list format for a number of things - but one thing it's very useful for is meeting notes - action items, topic headings etc.

• The need for better/easier systems administration can't be underestimated if increasing corporate appeal is the goal. Twiki as it stands is too "code hands on" for systems administration of a Twiki server. The installer I've written simplifies this rather dramatically to the extent that simplifies the case where someone is performing authentication using LDAP is simply a matter of answering a few simple questions.

• People who want to put lots of attachments on a TWiki server - eg exported powerpoint presentations - photos from a party - customer supplied archives/files tend to find the uploading one file at a time laborious. Zip files make life a lot simpler - but mean you have to download stuff to read it - which slows things down, and prevents instant access.

We also use a modified TWiki syntax for headings that's much more email like - which simplifies pasting emails & summarising emails into a TWiki page. Specifically something more like:

_*Centred Level 1 Heading*_
__Level 1 Heading__
_Level 2 Heading_
*Level 3 Heading*

This does overload the twiki operators again though, and I'd prefer to put these into a plugin - but then this'd need EnhancedPluginHandling. (Something which is definitely a better route to go down than continually extending the core.)

-- MichaelSparks - 28 Dec 2001

I think one thing needed for broad corporate appeal is the ability to provide some form of workflow handling. I would like to see the ability for:

• controlling access lists by changing a form (requires processing the form prior to scanning for access lists).
• ability of plugins to access changes to forms and validate these changes
• mechanism for returning the value of a piece of field metadata. % META% should probably be extended so that % META{"ProcessStage" type="Field"} will return the value of the ProcessStage field item.

I have a particular requirement for approval process support under TWiki.

-- JohnRouillard - 01 Jan 2002

Also it would be nice to fix the bug with rename of a page causing all pages linked to the renamed page to be marked as changed. This is discussed in DevOpinionPoll.

-- JohnRouillard - 01 Jan 2002

I really would like to see RefreshEditPage included (i.e. fixing the 'second edit in session loses first edit's changes' problem), even if as a configurable option - I ran into this issue when training a new user with IE5 (which usually doesn't have this) and it's quite disconcerting. It should really be the default, so that TWiki works correctly with browsers such as Mozilla and Opera, not just IE5/6 - currently TWiki is barely usable with Opera because you need to hit Refresh all the time when editing a page. I have tested this patch with various browsers and it works fine.

-- RichardDonkin - 04 Jan 2002

Is it possible to include VariableForCategoryDropdown to facilitate development of more dynamic search pages? AdrianLynch attached plugin for rewiew in VariableForCategoryDropdown topic. Thanks!

-- PeterMasiar - 13 Jan 2002

I'm happy to take a look at VariableForCategoryDropdown and generally at the space of making more use of the TWikiForm system. More shortly.

-- JohnTalintyre - 14 Jan 2002

John, I'm trying to puzzle out how to display the entries in a TWikiForm as a bulleted list instead of a table. (Not very actively, yet -- and perhaps someone has already told me that it is possible and how to do it -- I just haven't (re)found it.) If it is not possible, I would appreciate it if you could make modifications to allow it.

Thanks!

-- RandyKramer - 15 Jan 2002

do you want to put in the changes from DefineUserTopicBeforeRegistration and FileSystemNameClash ?

-- SvenDowideit - 15 Jan 2002

I noticed MichaelSparks' post from late December commenting about the need for better attachment handling. Is this a good place to plug our MultipleAttachmentsAtOnce post, which allows you upload a .zip file full of attachments, which then get unzipped and added as individual items?

We'd love it for it to go into the main codebase. Code's all there, just need someone to tell us how best to turn it over to your guys. Thanks!

-- VitoMiliano - 15 Jan 2002

Since I now have a good fix for BackFromPreviewLosesText, I've added it to the above 'nice to have' table - see that page for details. The fix is quite simple, it just sets some extra HTTP headers for the Edit page, solving the problem quite cleanly and thereby avoiding loss of edits. I'd appreciate it if the CoreTeam could review this for inclusion in the BeijingRelease. It depends on the RefreshEditPage changes to work well, but the code is separate.

-- RichardDonkin - 19 Jan 2002

Going back to the whole MorePluginHooks issue - I've revamped that page with a few requests, and a simple mechanism documenting what we have, what's been proposed, and why, whether they're accepted or rejected. Specifically also the BackFromPreviewLosesText details a problem that's essentially solved by adding extra headers to do with last mod/expiry - but these can be changed based on included content - which is what the extra preIncludeHandler hook is designed to help with. The nice side effect of this though is that this enables the "core code fix" to go into a plugin. The flip side to the same thing is at: LastModifiedFieldOfHttpHeader . I've got one small core diff to add in though for the hook.

The other nice thing this approach allows is for debugging of the system to be done through HTTP headers - the sample plugin for example dumps the last modified header & an X-TWiki-Date header so that we can compare & contrast whether the "correct" last modified header is getting dumped.

Combined with the TopicVarsPlugin this gives all sorts of fun possibilities...

-- MichaelSparks - 03 Feb 2002

Any interest in any of the stuff on SimplerTWikiDistribution this time around? I was thinking that the testenv script, which is tres cool, could actually relock the pages, since that really is a "setup time" thing and not a "ongoing maintenance" thing.

-- DougPhilips - 04 Feb 2002

I'm all for using plugins to add extra headers not needed by most installations, but the BackFromPreviewLosesText problem relates to IE5/IE6, which are by far the most common web browsers on intranets (even though MozillaBrowser works well) - IMO, TWiki should not require installing a plugin to work around this common browser bug. Perhaps there could be some core code to add the headers required for Edit, while a separate plugin does something similar to improve cacheability for View etc? Given that proxy caches are quite common on large intranets and have caused problems for TWiki users in the past (see SavePreviewTextOnServer and BrowserAndProxyCacheControl), it would seem reasonable to add the View cacheability headers to the core code as well, but that's a judgment call really.

-- RichardDonkin - 05 Feb 2002

If focus of this release will be to give broad corporate appeal, I guess also by simpler default installation, can we (I mean core developer team ):

• add excellent CommentPlugin as standard plugin installed with TWiki? Easy way to contribute will make buy-in simpler, IMHO.
• SimplerDefaultTemplates
• RenameTheTestWeb to Sandbox
• Split Main web to User (with user info), and maybe Home (or Main, or TWIKITOOLNAME), as discussed in RenameTheMainWeb, SeparateHowtoWeb, RenameMainWebToHome. User will be for user-related info, and Main or Home will be only for specific TWiki installation information.

-- PeterMasiar - 06 Feb 2002

Main.PeterThoeny said on 04 Dec 2001 - We need to decide on the strategy, feature set and schedule.

Just wondering... any indication of the schedule for the release?

-- MartinCleaver - 23 Feb 2002

What would be nice is also moving towards the goal of EasierUpgrades
-- ColasNahaboo - 23 Feb 2002

UPDATED COMMENT: Just want to register a vote(s) towards including the following in the Beijing release:

• NumberedHeadersAndLists (at least headers)
• CheckpointSave (this actually covers SaveAndContinueWorkingFromPreview which is on the list for Beijing)
• MultiSearchAddonDev, and integrate it on the WebSearch pages (or at least for Google, with a disclaimer that Google only indexes TWiki about once a month, so you (a user) may need the TWiki search tools for more recent stuff)
• The new TWikiDrawPlugin -- see ColasNahaboo comment of 22 Feb 2002 on TWikiDrawOnLinux
• StatisticsScriptGrepsMultipleWebs
• StatisticsUsingLessResources
• SimplerTWikiDistribution
• RenameMainWebToHome and UserWeb

PS: Isn't WebFastIndex somewhat done, and also PopupPageIndexForEditing somewhat accomplished by the same mechanism?

-- RandyKramer - 26 Feb 2002

to Add corporate appeal Since goal of this release is to give TWiki broad corporate appeal, let's check if we can do first something called in managerspeak easy winner:

• we have TWikiUnixInstaller, MultipleAttachmentsAtOnce,
• we have many nice skins, so we are ready for SimplerDefaultTemplates
• we have nice HighResolutionLogos
• excellent CommentPlugin simplifies user contribution and lowers entry barrier to 0
• we know we want RenameTestWebToSandboxWeb, RenameMainWebToHome
• we have patch for create UserWeb for users, cleaning Main (or Hone) web
• and most important: IE bug was fixed! (BackFromPreviewLosesText, fixed 95%),

So I think we have enough nice simple features, and one important bug fix to warrant new release - easy winner. I understand you guys wound like to have better Plugin features and what not, but why postpone new version for that?

One additional feature what I would like to see for broad corporate appeal is ApprovingRegistrations, and maybe ScriptToCreateNewWeb. But even without that, what we already have, TWiki deserves new release.

Do not forget we need to agree on SimplerDefaultTemplates and then modify documentation (WelcomeGuest etc) accordingly. So this release will need broad changes in documentation (= time), while Plugin changes are more transparent for newbie.

Can I ask (beg) CoreTeam to add possibly some ready patches, and roll out BeijingRelease? Pretty please?

Who is with me? We want BeijingRelease!

-- PeterMasiar - 27 Feb 2002

I agree about a simpler TWiki distribution and with many of the feature requested, although of course feature creep is always an issue... It does seem to be hard to get the many great TWikiPatches into the distribution, even when they are very localised bugfixes for data loss bugs such as RefreshEditPage and BackFromPreviewLosesText - however I'm not on CVS so for all I know they've been fixed on the email list... Presumably the CoreTeam are just very busy?

I've also just written the WindowsInstallCookbook, ported testenv to ActivePerl and got it to provide more info (see CookbookActivePerlTestenv), and fixed a long standing bug with path_info in CobaltRaqInstall (applies to hosted environments as well, where they use cgiwrap, and to IIS). So I'm not just complaining, honest

Would it help if I volunteer to work on some of these bugs, and on putting WindowsInstallCookbook into the documentation set under the TWiki web? Or would I need to be a CoreTeam person?

-- RichardDonkin - 27 Feb 2002

I've added WindowsInstallCookbook to the above since it's been tested successfully by three people and works well. Note that it also includes a patch to register that should be applied to BeijingRelease, since register currently doesn't work on Windows (as mentioned near end of AuthenticationProblem) - see step 5 within WindowsInstallCookbook#Editing_the_CGI_scripts.

I've also added:

• CookbookActivePerlTestenv - the attached testenv now works well on Windows (ActivePerl and CygWin) and Linux/Unix, across various Perl versions. It also tests for path_info problems, checks whether ModPerl is being used, provides better Perl version info, checks the RCS version on Cygwin, and correctly tests for ci.exe etc on Windows.
• CobaltRaqInstall - the fix here will help in various hosted environments that use cgiwrap, as well as in IIS where the path_info is messed up.

It would also be good to review TWikiPatches for relevant bug fixes - some are very simple to include.

-- RichardDonkin - 03 Mar 2002

Sorry, very busy lately, could not spend as much time as I wanted on TWiki.

Schedule is not fixed yet, but we have around two releases per year. We could shorten the schedule with less features, or put in more enhancements with longer schedule. Opinions?

This release should give broad corporate appeal but without compromising the stability. So, we should not make major code changes unless tested extensively. The only major code change is RcsLite. John, shall we include it / drop it from this release, or decide later?

-- PeterThoeny - 08 Mar 2002

A lot depends on the date for the release. The main change will be for store etc to go via new Data backend and consequent change in TWiki.cfg. RcsLite would in my mind intially be an option for people to try rather than for serious live use. That would change when enough people where happy with it.

-- JohnTalintyre - 08 Mar 2002

Took the liberty of moving some suggestions up to the table for the "Nice to Have" list (below the statistics line). Progress has been made on many of these, but perhaps as patches or plugins rather than specifically as additions for the next release.

-- RandyKramer - 08 Mar 2002

Re: Release frequency. I think it would be nice to have a "2 major, 2 minor" annual release cycle. Sometimes it's hard to find intrim patches or to know if they're necessary or what. My idea would be to have the spring and fall releases be major (and fall more major then spring - see below) and the summer and winter releases be minor. The reason for having the fall release more major then the spring major release is in consideration of how people work: they're settling down in front of their computers for the cold months (ok, N. Hemisphere-centric), and have/will want to spend more time doing TWiki things.

I would also suggest naming them as "TwikiSummer2002", "TwikiFall2002" (for example) and using the solistics and equinoxes as target dates so one doesn't have the weird situation of the 1 Dec 2001 release coming on the 12th or whatever it actually was

-- DavidLeBlanc - 08 Mar 2002

Yeah, more releases would be nice. Also, I tidied up the table a bit. Someone broke it.

-- VitoMiliano - 08 Mar 2002

That was probably me (that broke the table) if you're referring to the items that I put below the statistics line, and I'm doing it again today. I'm adding ProblemWithAnchorLinks to the nice to have table, but I feel it appropriate to put it below the statistics line until somebody like PeterThoeny "accepts it". Maybe that's not appropriate, but in a way, I felt it wasn't appropriate for me to modify the table, but I think it gives an item just a little bit more attention, and since there is already a patch (perhaps not thorougly tested), it should not be a major development effort.

Maybe PeterThoeny wants to express a preference about how to handle items like this.

-- RandyKramer - 29 Mar 2002

"TwikiSummer2002", "TwikiFall2002" - who's Summer? NZ is firmly in Autumn now....

-- MartinCleaver - 30 Apr 2002

TO-DO: Meanwhile, there's one simple thing that can be done quite easily, that MAY help the situation greatly: fix the main templates!

1. hardcoded settings into variables: the robot - imageHome.gif in twiki.tmpl into %LOGO%; the white body bgcolor in view.tmpl into %PAGEBGCOLOR%. Etc. And add attributes with variables.
2. heavily comment the templates: twiki.tmpl and view.tmpl. separated each section with spaces, explained what part of the page each defined, described the VARIABLES and the template defs, commented on the hardcoded stuff, made suggestions. For the view.tmpl, added a bunch of spaces in the head area and noted: DROP SCRIPTS AND STYLES, OR LINKS TO EXTERNALS, HERE! (Apache httpd.conf file style!) I started on commenting these - will post.
   • _the problem with comments in the templates is that they are passed on to the browser. Unless there is a way to comment without using html

     <!-- -->

     which I'm not aware of? This really cries for a bootstrap approach: use Twiki to build Twiki templates. -- MattWilkie _

Doing just those two things, along with a barebones version of NewContents docs set-up, could make a huge difference. It becomes a more step-by-step process getting into TWiki, fully adjusting the basic look, while being intro-ed to many TWiki features and the general set-up, while still just following instructions.

(There's some stuff in lib modules, like the kinda green on the forms and tables. Can those be pulled out?)

All this would be great with whatever else, skins, cookbooks...

Included this bit. Time to pack it in now...

-- MikeMannix - 19 May 2002

Just trying out the new GaugePlugin. I had to change the sequence of initializing the plugins in TWikiPreferences, that is, SpreadSheetPlugin needs to be before the GaugePlugin. (Added the gauges also for the "nice to have" list, ThomasWeigert)

-- PeterThoeny - 24 May 2002

Moved the plan to include CommentPlugin from "to-do" to the "nice to have" list. We should include it in the release once the topic locking issue is resolved.

-- PeterThoeny - 24 May 2002

Not clear why any plugin, in particular this one, should be in the main release. It is very easy to add a plugin... As with any additions, feature creep is an issue and plugins allow to keep that under control by installing only what you want. (Regarding the comment plugin, I did not find that to be an enhancement over just editing the topic. An option of editing without preview maybe more useful?)

Also cleaned up the ProperIncludeUrls in the "nice to have" list, as there was a spacing problem with this row.

-- ThomasWeigert - 26 May 2002

I am inclined to agree with Thomas, even though I'm flattered However, maybe Peter can clarify? One of the challenges with CommentPlugin was the processing steps it went through -- it didn't fit into the normal "plugin" rules.

One thing I'd like to see, and maybe this is what Peter is saying, is that a "common" set of popular plugins be supplied pre-configured with a TWiki deployment (along with a set of popular skins, like Koala). I think that would dramatically raise the "ease of use" feature.

I really like the GaugePlugin too! The more "project management" oriented features TWiki supports, the better I think this product will survive!

-- DavidWeller - 27 May 2002

A few plugins (like InterwikiPlugin) and skins preconfigured in the TWiki distribution would make the initial deployment easier as long as they are not in the way. As such, the CommentPlugin would fit into this category. Plugins can be disabled easily, but it KISS is important too...

-- PeterThoeny - 29 May 2002

I am not quite sure how, but that definition, TWikiDrawPlugin made it on the "nice to have" list. It is a great plugin, but certainly not part of a standard distribution?

-- ThomasWeigert - 02 Jun 2002

I agree, its strange, but one could ask the same question of what determines which plugins get installed on TWiki.org. I don't ask anymore.

I've changed the stats for ApprovingRegistrations on the Nice to have list. Not because I've made any changes but because I think the stats listed were unrepresentative of the work that Kevin has already done.

-- MartinCleaver - 13 Jun 2002

I added replacing GMT with server time to the table marked for "All" in BeijingRelease, in the hope that someone will consider making it a reality. On an intranet only one time zone needs to be used, for all but the really big multinational companies. If it is a local intranet where time stamps are really useful, then GMT is harmful.

The code in SettingCorrectTimeZone is in current use by a few people including myself, but needs more testing. I found only one problem, illustrated at SimpleTemplateCompromise, which I hope might be solved by sending -zLT to rcs commands but I still have to investigate.

If this almost ready code cannot be perfected and folded into Beijing release as an option, at least consider putting instructions into the shipped docs, or explaining how to remove all confusing references to date and time. In some companies, GMT will be the ultimate show-stopper for TWiki. (Note that I am not advocating for user time zones, but just the one option of configuring for server time instead of GMT)

-- SueBlake - 11 Aug 2002

I second SueBlake's comments regarding GMT. The ultimate, of course, would be to display the time in the user's time zone....

-- ThomasWeigert - 13 Aug 2002