Session Start: Mon Sep 01 21:00:49 2008 Session Ident: #twiki_release [21:00] * Now talking in #twiki_release [21:00] * Topic is 'http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x08x18' [21:00] * Set by Lavr on Mon Aug 18 19:45:54 [21:00] Hey ho! [21:01] Hi there! :) [21:01] Hi Markus [21:02] I see we are the magnificant amount of 3 [21:02] I had not expected a huge audience tonight. [21:02] Has the meeting been announced on #twiki, too? Maybe they forgot? [21:02] Ah, done. :) [21:03] * EugenMayer has joined #twiki_release [21:03] It will be a short meeting tonight since we have the Summit later this week [21:03] Hi Eugen [21:03] Hi together. I have missing some meatings, hope i can catch up again properly next times [21:04] BB in one minutes [21:05] Anybody here with a live TWiki. Just want to test something, 5 seconds time ( just until we did not start here) [21:05] I am back. [21:05] What do you want to test? [21:06] just go to a topic you have an attachment. Copy the link, logout [21:06] open a new window, paste the link and add a ?t=foo to it [21:07] try to access. Oh yeah, it must be a wiki which restricts access to attachment through viewfile [21:07] * carlo__ has joined #twiki_release [21:07] i first though it is a problem with my twiki or might be 4.1.2 but it seems to be a bug in the rewrite rule [21:07] http://merlin.lavrsen.dk/twiki42/bin/view/Myweb/AttachmentWorks has plenty of attachments and runs the current TWikiRelease04x02 [21:07] which will all use i guess [21:08] Lavr: does it restrict acces throug viewfile ? [21:08] My merlin.lavrsen.dk does not have restrict access for viewfile [21:09] Then we cant test it [21:09] moin [21:09] its all about http://twiki.org/cgi-bin/view/TWiki/TWikiAccessControl#Controlling_access_to_Attachment [21:09] not many peopla around... [21:09] hi Carlo [21:09] It is the bug just raised about the viewfile thinking the dot is web.subweb? [21:10] I expected a small croud today [21:10] Lavr: no, the other thing is diffrent and it is version related ( i think ) [21:10] I have not put any proposal for discussion. And I did not plan any bug walk through [21:11] I never tried to limit access to attachments because that would slow down TWiki to a halt in practical use. [21:11] Clearly an issue we should address [21:12] Lavr: with the exception of pictures and twiki web it does not slow down the way you think [21:13] we just need some advanced reg-exp for skipping all pictures. all things in TWiki web are not tunneled through viewfile already [21:13] Yes. It is the TWiki web that is the problem only [21:13] sorry. Have to leave [21:13] bye [21:13] Lavr: that is not a problem at all [21:13] Bye [21:13] * carlo__ has quit IRC ("ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]") [21:13] RewriteCond %{REQUEST_URI} !^/+twiki/+pub/+TWiki/+.+ [21:13] that means, "if its in twiki/pub/TWiki" ..dont use viewfile, go directly [21:14] so anything like CSS files or Layout/theme pictures are not tunneled through viewfile [21:14] Hmm. We need a good document to define this. [21:15] More like a script Lavr. you enter a Whitelist for directorys you dont want to be tunneled. Also you can entered file-extensions ( pictures and stuff ) you want to access directly [21:16] The non geek way would be that the access rights are defined from access to the topic. [21:16] Anything else is >5 on the NerdoMeter [21:16] Nope, just use some frontend like ApacheConfigGenerator [21:16] And it is an admin task anyway, to restrict and tune [21:17] That sounds intuitive; unfortunately, quite a number of Plugins bypass this by accessing the files on disc :( [21:18] There is a significant performance hit on using viewfile. [21:18] Yeah, but if you configure it only to trigger when you need it, it works fine [21:18] If you have a topic with 20 pictures - you can end up with 20 seconds delay to load the pictures [21:19] If a topic is open for anyone to look at - why should its pictures be served by a perl script? [21:19] and we should give that to the responsibility of the admin to choose "i need this at any costs or not". Otherwise, TWiki just disqialifies itself with a "no go" for specific task / enviroment [21:19] Lavr: as i said, just a good regexp which does not load pics thorugh viewfile [21:19] One way could be that attachments are saved in one of two directories depending on the access rights. [21:20] that sounds not bad [21:20] An apache regex cannot know of an individual topic has an ALLOWTOPICVIEW defined. [21:20] i get your point [21:21] Let me just check if there are any urgent bugs worth us present to discuss. [21:21] We can scratch Item5581, btw. It has been rolled out w/ 4.2.2. [21:22] AndreU did commit the fix, but we both forgot to change the status. [21:24] Was it committed in both trunk and T..04x02? [21:24] Yes. [21:24] OK I clode [21:24] I don't know why only one commit shows up there, though? Is this filtered? [21:24] close [21:24] I cannot say why either [21:28] [21:25] We have quite many release blockers. Seems like we will have a 4.2.3 in late September. [21:28] [21:26] The 4.2.2 was a very quick release so it is not surprising that we will have a follow up one month after 4.2.1 [21:28] [21:26] Item5926: Topics with Chinese in UTF8 destroys page view in Internet Explorer [21:28] [21:27] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5926 [21:28] [21:27] I have actually analyzed this in detail and I know the root cause. [21:28] [21:27] The suggested patch from the reporter is to URL encode the anchors... but.. [21:28] [21:28] Lavr: wrong window? [21:28] [21:28] dammed. [21:28] [21:28] yes [21:28] Thanks ;-) [21:28] :-) [21:29] ...but? ;) [21:29] but the real root cause is that there is code that truncates the anchor length [21:30] and this does not assume unicode format [21:30] So it can truncate a unicode char in the middle. [21:31] its not human, it wont cry! [21:31] We have MANY of this type of bugs with utf-8 and each time we add an encode/decode to fix it we do not resolve the root of the problem [21:31] But... if it truncates the anchor length, it should also truncate the reference? Shouldn't that fit again? (ok, it's a bug...) [21:31] I have been in doubt what the right fix is but I have not had time to email Richard about advice. [21:31] reading the bug and the comments, i cant get why the whole layout is broken because of a non unicode char? is IE interpretating some chars as "HTML markup" ? [21:32] Yes. A UTF-8 16 bit char chopped in half sometimes ends up as > or < [21:32] and that typically breaks things [21:33] And... why is the length of the anchor truncated in the first place? Isn't the rendered page XHTML conformant? [21:33] ok fine. Later in the story, the sol. should be URL encoding BUT as someone is cutting the lenght, this could case a non match [21:33] s /conformant/compliant/ [21:34] Yes. I guess the author behind this wanted to avoid a 250 char anchor [21:34] i mean in the end, the anchors length is limited by the GET protocoll [21:34] -l [21:34] There is an old Codev discussion where someone wanted utf-8 type anchors so I am not sure we should URL encode. [21:34] I would suggest an alternate implementation: If the anchor is too long, replace it with it's hexadecimal hash code. [21:35] (plus some unique prefix) [21:35] what about URL encode, before cutting, decode, cut, encode? [21:35] Also the URL encode creates the code for half a utf-8 char which could still cause trouble [21:35] uebera||: but the anchor is useless then, or? [21:36] If it is legal in the first place, the code's wrong. If it refers to a TWiki reference, that one should be converted, too. So it should fit. [21:36] I am not sure what is the most correct way to handle it. I found some resources that suggests anchors should be URL encoded [21:36] Lavr: anything in the URL shoudl be URL endcoded :) [21:36] so the anchor should [21:37] But then at least the URL encoding should encode an entire utf-8 char and not the first 8 bit of it [21:38] I do not want to alter the truncate code because we also need to preserve the anchors because quite many users abuse the TOC anchors [21:38] I see this all the time at work.' [21:39] I think I will email Richard Donkin (spelling) and ask for advice. [21:39] Beside my "issue" with the attachment is solved. It was completely browser related [21:40] Oh. Really? [21:41] yeah, that ?t=102121221 argument was telling my browser to "cache" it [21:41] when i first access it logged-in [21:41] so, basically, to solve this, the encode/truncate/decode code should "use utf8" (utf8::upgrade, is_utf8, ...) iff TWiki is set to use utf8 encoding? [21:41] then, using this link again ( even with clearing the cache...thats odd) he gets it from the cache [21:41] EugenMayer: To rule out caching probs, I use konqueror for tests instead of Firefox. [21:41] uebera||: good idea. [21:43] Markus. What worries about UTF-8 is that we end up everywhere with perl code not knowing that specific variables are UTF-8 strings. And not even Crawford is comfortable with how to handle this in general [21:43] We really need a UTF-8 expert on the project [21:45] (Kenneth reminds that we have a release meeting in progress) [21:45] Lavr: RewriteCond %{REQUEST_URI} !^/+twiki/+pub/+([^/]+)((/+([^/]+))+)/+([^.]+)\.(jpg|jpeg|gif|png|JPG|GIF|PNG|JPEG)(.*) [21:45] Wrong window the other way [21:45] Lavr: using this, even with the attachment file acces restriction, pictures are showing not though viewfile [21:46] I have plenty of topics where we would like to have also jpgs and pngs that are in restricted topics blocked [21:47] Imagine a topic with a new not yet released org chart in a gif or png attachment. [21:47] The only way to address this would be to introduce prefixes (utf8_string) in the code, I guess. [21:47] Markus. No because the encoding depends on the configure setting AND the format of the stored topics. [21:48] Lavr: its not a overall solution, its just a kind of "while" hack. Most pictures are not critical. Or if you know, you zip them, or use a format you dont include in the regexp :) [21:49] Normal people will never figure out which format is protected and which are not. It has to be something that is automatic based on access rights for the topic and web [21:49] Guys iam not quite aware of what all this UTF8 problems in the code are. i mean, in code, we handled this by using "use locale", so that all encoding critical operations respect the current encoding, right? [21:50] We have the use locale in TWiki. But somehow as variables are handed over from sub to sub and class to class the information that a variable is utf-8 gets lost [21:52] Lavr: what encoding variables have to be, is set in the configuration, so why we should need that informatoin. In addition, "internal" encoding could be diffrent, but this is to handle seperated i guess [21:52] Hm... the 'only' problematic place are those which try to encode/decode/truncate strings, right? If we introduced some kind of wrapper function which includes is_utf8, this should work. There may be a performance penalty, though. I have to test this first, however (next month, unfortunately, this month is really busy for me). [21:53] Hey, we could ask "what's the best strategy to make your legacy Perl application handle UTF8" on /. ;) [21:53] (changing the names to protect the innocent, of course) [21:54] :-) [21:55] Actually i would like to read into that problematic, but iam to new to perl and have to learn that XSL stuff right now [21:55] This would be a perfect occasion to use aspect-oriented programming :( [21:55] All that encoding things will face me 1000x times in the future, so there is a point to learn it properly [21:56] Actually, did someone test TSA ? [21:57] I most likely didn't, because that acronym means nothing to me ("Transportation Security Administration"?) [21:57] because we speak about performance form time to time when implementing, but isnt the stand-alone approach a real solution of twiki ? [21:57] Twiki Standalone, or ? [21:57] Ah, got it :) [21:57] No, unfortunately, not yet. [21:58] I did not really test TSA either because of the many open issues. I have been focused on releasable code. [21:59] ie the TWikiRelease04x02 branch [21:59] yeah, everytime i hear that [21:59] i ask myself, when i finally can upgrade [21:59] i hope i start it when travelin to berlin [21:59] i really have to finish all the other projects to finally concentrate on twiki [22:00] Some of my projects will never by finished, unfortunately ;) I have to win in the time lottery or build me a time machine someday. [22:01] I never so any TWiki devel at work. No chance in hell. All my TWiki time is evenings and weekends. I have no kids and a career woman as wife so I have some hours most days [22:02] My problem is, iam not earning money with twiki right now [22:02] but i have to earn money, so i have to do other stuff before. mostly i dont manage to have time left [22:03] but currently iam planing to use twiki a central biussness and thats where i can investigate much more time in core-dev, but first i have to finish all that marketing stuff .. [22:04] i planed to develop in 4.2.x in before 2 months or so, when the governance discussion was flaming up, but iam still behind.. [22:07] Does anyone have any other bug items to discuss tonight? [22:09] I don't. [22:10] OK. Does anyone wish to discuss a feature proposal tonight? [22:10] which is item 2 on the agenda [22:10] Hmm [22:10] I looked at the list and did not find any obvious ones that needed decision [22:10] I have been to the FrOSCon with Oliver [22:10] I don't. :) [22:11] and talked to some OpenOffice guys. Afterwars i realised that sun has a plugin for OpenOffice to edit MediaWiki topics. I think, this is not something we should miss to long [22:11] * AndreU has joined #twiki_release [22:12] It would be nice with an OpenOffice type access to TWiki yes. [22:12] I'll add an action item ("play with TWiki+UTF8") for myself next month... [22:12] That would be nice :-) [22:12] i think its just the next step after WYSIWYG. I mean, it has the same roots, all devs saying "it an overload" 8 same for WYSIWYG in the past) but its really cute for editing [22:12] Lavr: you will be on the summit ? [22:12] because i plan to presentate such an access [22:12] Eugen. I am the host at the meeting - so yes :-) [22:13] Damn, teh motorola-guy [22:13] my brain is wasted [22:13] Ah, though luck... I would have loved to be there... hopefully, I'll manage next time if it's not too far away. [22:13] You all need to bring a picture ID. Drivers license is fine. [22:13] Iam sorry Kenneth. Its just the younger people you know... [22:14] I am getting "old" too. (43) [22:14] pictureID, what will that for? [22:14] for the entrance stuff ? [22:14] To identify yourself at the reception and get a guest tag. [22:15] Ok fine [22:15] I have to give your names and company name to the reception the day before. [22:15] * AndreU has quit IRC (Client Quit) [22:16] Actually, is there a number? How many are we? Sven will be missing, Markus too [22:16] CDot, Kenneth, Oliver, Michael, Andre, Eugen [22:16] I will open the same conference bridge as we used for the two Governance meeting. Also same PIN code. [22:17] We will open an IRC channel and give the numbers there. [22:17] Great! :) [22:17] I do not want to put the numbers and PIN public on the web. [22:18] sure [22:18] Actually Kenneth, what about internet there ? [22:18] It is important that you put your name on http://twiki.org/cgi-bin/view/Codev/TWikiCommunitySummitBerlin2008Q3 [22:19] I hope I have a large enough room :-) [22:19] Iam thin. [22:19] If the list holds it will be the largest Summit of the 3 [22:19] wow, that are quite some guys [22:20] Yeah we seem to be 16 now [22:20] In rome we were 12 and similar in Sunnyvale [22:21] Shows TWiki is a German project :-) Denmark being sort of North Germany [22:21] I think its the german touch! [22:21] ;-) [22:21] hehe [22:21] My biggest challenge will be to hide from my factory [22:22] Half of the staff there wants my help.... [22:22] and the other half wants to kill me :-))) [22:23] Thats quite normal for anybody in touch with IT [22:23] dont worry, 16 IT guys will help you out fighting back [22:23] :-) [22:24] I actualy enjoy working with my Berlin colleagues. Wonderful people ;-) [22:27] ok guys, iam off for relaxing a bit [22:27] One last thing [22:27] Please review http://twiki.org/cgi-bin/view/Codev/TWikiGovernanceConsolidated [22:27] I will [22:27] This is my attempt to join the TWikiGovernance proposal and the TaskTeam proposal. [22:28] Crawford and I talked on Skype for 2 hours yesterday [22:28] Will do, too. [22:28] And I encouraged him to REFACTOR and not discuss the proposal [22:28] And he did. [22:29] So this means we have now moved the two proposals towards each others and identified the details that we need to discuss and agree. [22:29] i read it up tomorrow to get all the details. Any further lecture for the summit? [22:29] It is much easier for us to discuss specifics than discussing one suite against the other [22:29] The other important lecture is the TWikiRoadMap [22:30] The TWO things we have to get out of the Summit is - significant progress on Governance [22:30] AND an updated RoapMap with more specific details [22:30] But equally important is to..... [22:30] Sounds reasonable [22:31] ... have fun together [22:31] ... get ideas from each other [22:31] :) [22:31] The latter is why we show each other how we use TWiki. [22:32] Being at Motorola I have the chance to show how we use TWiki in practical. [22:32] well, thats great! [22:32] It will be good if you bring some examples. [22:32] Was that for me ß [22:33] For all of you. [22:33] all 3 :-) [22:33] :-) [22:33] I love to see how others use TWiki. I love to get ideas for apps [22:34] If you got internet i will show my application too [22:34] without internet it can be a bit more difficult [22:34] I'm currently mainly playing with kinosearch and modify a lot of plugins to be able to typeset my phd thesis using TWiki... ;) [22:35] We may have internet. One is working on setting up a laptop as a gateway to a flatrate 3G phone [22:35] thats oliver [22:35] I may also be able to make a wireless link to an open line. But I cannot guarantee this [22:35] i guess we will see [22:35] I will have access via a firewall as a Motorola employee [22:35] * EugenMayer has left #twiki_release ("Kopete 0.12.7 : http://kopete.kde.org") [22:36] OK. Thanks for participating. [22:36] gn8 ;) [22:36] Good night [22:38] * AndreU has joined #twiki_release [22:44] * AndreU has quit IRC