Release Meeting: 18 May 2015

Details

• Date: 18 May 2015 1300Z
• Location: IRC #foswiki-release
• Log: (See inline at end of this topic)
• Participants (Add/Delete)

• Prior attendees
  • GeorgeClark (gac410)
  • MichaelDaum
  • JanKrueger (jast)
  • LynnwoodBrown (lynnwood)
  • JulianLevens
  • MarkusUeberall (uebera||)
  • CrawfordCurrie (CDot)
  • AndreLichtsteiner (andreli)
  • jomo
  • StephanOsthold (ModAcOst)
  • AaronFuleki (tsnfoo)
  • MaikGlatki (mglac)
  • TerjeAndersen
  • TimothyLegge (timlegge)

1. Character set issues: Tasks.Item13378

A lot of work has been done on this by CrawfordCurrie in the utf8 branch as a result of this fantastic work CrawfordCurrie was soaked by the team in virtual beer.

Jomo has done quite a lot of ad-hoc testing on these changes.

The consensus was to merge this back into master and move forward even though it's a relatively large change this late into a release it does fix some important issues. Some changes were requested to the utf8 branch to standardise using web= and topic= parameters for the enhanced SCRIPTURL and PUBURL macros.

GeorgeClark said that he will looking to create the next Beta with these changes merged later this week.

This is a major issue that is blocking Beta 2. From the task:

CGI returns all params (including path_info, url etc) in UTF-8 encoded byte strings. By happy coincidence, this is how perl internally represents UNICODE, so these strings appear to be UNICODE to most perl applications. Foswiki, in many places, does not decode these byte strings to the {Site}{CharSet} (topic and web name parameters, attachment filenames etc etc), However all strings output in the HTML must be output using the {Site}{CharSet}. So long as only 7-bit characters are used, this is not a problem, but as soon as wide-byte characters are involved, it all falls apart.

There are two approaches to solving this:

1. Call Foswiki::UTF82SiteCharSet() everywhere a parameter value is destined to end up in HTML output
2. Convert all param() etc inside Foswiki::Request so they are decoded to the {Site}{CharSet} before the ->param( call.

There will be cases where, through accident or design, the encoding currently "just works" or is explicitly converted. Some plugins (TopicInteractionPlugin for example) perform the conversion themselves, which makes a blanket conversion unworkable. Note that URI parameters are used in many places, and are even stored (e.g. in the cache, or in the CGI session) for future use.

Bottom line, what we currently have is badly broken for any {Site}{CharSet} other than utf8. We cannot release the way it is. I have started the process of (1) above, but it looks like there may be a lot of edge cases (e.g. usernames nd passwords; do we support wide byte chars in them?)

This is the one remaining major blocker.

2. Proposed Schedule for Alpha / Beta / GA

• Beta 2: Merge in Item13378 changes from utf8 branch, later this week

Next actions

1. When we merge, need to consider impact on trunk / release web sharing on t.f.o & f.o
2. GeorgeClark to raise task ref possible sorting issue with EditRowPlugin and/or TablePlugin

Next meeting - - Monday Jun 01, 2015 1300Z — ReleaseMeeting01x02_20150601

IRC Log