Date: November 21, 2012 11:09:55 PM PST
Subject: JerusalemMeetingLog2012x11x22.txt

[8:49pm]  HideyoImazu joined the chat room.
[9:01pm]  MahiroAndo joined the chat room.
[9:01pm] MahiroAndo: hello
[9:01pm] PeterThoeny: hi HideyoImazu-san, MahiroAndo-san
[9:01pm] HideyoImazu: hi peter
[9:02pm] MahiroAndo: Hi Peter
[9:02pm] PeterThoeny: thanks for making it one day early
[9:02pm] HideyoImazu: no problem
[9:02pm] HideyoImazu: it's better for mahiro and me
[9:02pm] MahiroAndo: I appreciate it too
[9:02pm] PeterThoeny:
[9:03pm] PeterThoeny: what's new?
[9:03pm] HideyoImazu: it gets much colder in Tokyo
[9:03pm] PeterThoeny: move to the silicon valley!
[9:04pm] HideyoImazu: i can stand tokyo winter because i was born and raised in a much colder
area in japan
[9:04pm] PeterThoeny: tonight we went to ringer hut to eat nagasaki champon nabe
[9:04pm] PeterThoeny: where did you grow up?
[9:05pm] HideyoImazu: central part of japan near nagoya
[9:05pm] PeterThoeny: where? i know that region
[9:06pm] HideyoImazu: gifu prefecture
[9:06pm] PeterThoeny: what city?
[9:06pm] HideyoImazu: ogaki city
[9:07pm] PeterThoeny: oh, i have friends there
[9:07pm] HideyoImazu: it's a small world
[9:07pm] PeterThoeny: they run the tokushji
[9:07pm] PeterThoeny: tokushuji temple
[9:08pm] PeterThoeny: i once went by bicycle from nagoya to their temple and back
[9:08pm] PeterThoeny: small world
[9:08pm] PeterThoeny: indeed
[9:09pm] PeterThoeny: let's start, it looks like just us
[9:09pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/JerusalemReleaseMeeting2012x11x22
[9:09pm] PeterThoeny: 1. Feature Requests for Jerusalem Release
[9:09pm] PeterThoeny: 2. Review Urgent and Not So Urgent Bugs
[9:09pm] PeterThoeny: 3. Extensions
[9:09pm] PeterThoeny: 4. Miscellaneous
[9:09pm] PeterThoeny: any other item?
[9:09pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/TWikiFeatureProposals
[9:10pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/SaveRedirectToAutoinc
[9:10pm] PeterThoeny:  Feature Proposal: AUTOINC in the redirectto parameter of the save script
to be replaced by the AUTOINC number - by hideyo-san
[9:10pm] PeterThoeny: i am not clear on use case, but looks good
[9:11pm] PeterThoeny: do you want to vote now to accept?
[9:11pm] HideyoImazu: i'll put a real use case or two
[9:11pm] HideyoImazu: can we vote now?
[9:12pm] PeterThoeny: yes, proposals can wait for 7 days, or we can discuss and build consensus
at release meeting
[9:12pm] MahiroAndo: it looks good to me
[9:12pm] PeterThoeny: and thus decide at release meeting
[9:12pm] PeterThoeny: ok by me
[9:12pm] PeterThoeny: since you won't object your own proposal it looks like it's accepted by
release meeting
[9:13pm] HideyoImazu: cool
[9:13pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/RenameTopicNoReplIntRefs
[9:13pm] PeterThoeny:  Feature Proposal: The rename topic operation to have option not to replace
web internal references - by hideyo-san
[9:13pm] HideyoImazu: i replied to you comment on the page
[9:14pm] PeterThoeny: just saw
[9:14pm] PeterThoeny: looks like we are in agreement
[9:14pm] PeterThoeny: NOREPLINTREFSCHECKBOX looks a bit cryptic
[9:14pm] HideyoImazu: agreed
[9:14pm] HideyoImazu: any suggestion?
[9:15pm] PeterThoeny: NOBACKLINKCHECKINCURRENTWEB ?
[9:15pm] HideyoImazu: ok
[9:16pm] PeterThoeny: and label could be: No back-link check in current web
[9:16pm] PeterThoeny: or: Skip back-link check in current web
[9:17pm] HideyoImazu: mmm
[9:17pm] HideyoImazu: it's not about back links, i'm afraid
[9:17pm] HideyoImazu: back links are links from other topics to a topic
[9:17pm] HideyoImazu: righ?
[9:18pm] PeterThoeny: in a way it is, no?
[9:18pm] HideyoImazu: this is about links to other topics in the same web.
[9:19pm] PeterThoeny: if you don't check the backlinks in current web it means you will not fix
links
[9:19pm] PeterThoeny: may be i misuderstand?
[9:19pm] PeterThoeny: "misunderstand"
[9:20pm] HideyoImazu: not quite
[9:20pm] HideyoImazu: there are two kinds of link fixing when a topic is moved.
[9:20pm] PeterThoeny: i just re-read
[9:20pm] PeterThoeny: you are right
[9:21pm] PeterThoeny: there are back-links (in-bound), and links to other topics (out-bound)
[9:21pm] HideyoImazu: yes
[9:22pm] PeterThoeny: so, what about in-bound, wouldn't you need to ignore those as well?
[9:22pm] HideyoImazu: you can ignore in-bound links by uncheck all the back link checkboxes
[9:22pm] PeterThoeny: true
[9:23pm] HideyoImazu: with outbound links, no option right now
[9:24pm] PeterThoeny: so in a way it is "do fixing with web-prefix"
[9:24pm] PeterThoeny: sorry, "don't add web-prefix on move"
[9:24pm] HideyoImazu: bingo
[9:25pm] PeterThoeny: twiki adds/removes web-prefix as needed to keep valid links
[9:25pm] HideyoImazu: yes
[9:25pm] HideyoImazu: twiki does the right thing in most cases with outbound link fix
[9:26pm] HideyoImazu: but there are cases where you need to suppress it
[9:26pm] PeterThoeny: so, verbatim it would be "don't prefix topic with web name when topic is
moved to another web"
[9:26pm] HideyoImazu: exactly
[9:27pm] PeterThoeny: so what is a good and not too long name for preference setting?
[9:28pm] PeterThoeny: NOWEBPREFIXONMOVE ?
[9:29pm] PeterThoeny: DONTADDWEBTOTOPICONMOVE ?
[9:29pm] HideyoImazu: we are talking about a preference variable name to display such a checkbox,
right?
[9:29pm] PeterThoeny: yes
[9:29pm] HideyoImazu: do those names sound like dictating what to do rather than whether or not
display the checkbox?
[9:30pm] PeterThoeny: you are right
[9:30pm] PeterThoeny: NOWEBPREFIXONMOVECHECKBOX
[9:31pm] PeterThoeny: we already have checkbox enables
[9:31pm] PeterThoeny: ATTACHLINKBOX
[9:31pm] HideyoImazu: NOWEBPREFIXONMOVECHECKBOX looks fine.
[9:31pm] PeterThoeny: is an existing one
[9:32pm] PeterThoeny: FORCENEWREVISIONCHECKBOX
[9:32pm] PeterThoeny: DONTNOTIFYCHECKBOX
[9:32pm] PeterThoeny: ok decided
[9:32pm] HideyoImazu: NOWEBPREFIXONMOVECHECKBOX seems to fit with existing ones
[9:33pm] PeterThoeny: yes
[9:33pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/TagMePluginWithMultipleTagNamespaces
[9:33pm] PeterThoeny:  Feature Proposal: TagMePlugin with multiple tag namespaces support - by
yaojun
[9:33pm] PeterThoeny: yaojun and i had a discussion
[9:34pm] PeterThoeny: he wants to have plugin data in pub dir
[9:34pm] PeterThoeny: this is because we have no standard yet on how to handle working dir data
in multi-site installation
[9:35pm] PeterThoeny: have you considered a way to handle working data?
[9:35pm] HideyoImazu: sort of
[9:35pm] HideyoImazu: there are two kinds of "working data"
[9:36pm] HideyoImazu: 1) temporary and/or site specific
[9:36pm] HideyoImazu: 2) permanent and subject for mirroring
[9:37pm] HideyoImazu: 1) can be in the standard work directory
[9:37pm] HideyoImazu: but 2) is better to be in pub
[9:37pm] HideyoImazu: more specifically pub/WEB
[9:37pm] PeterThoeny: or as i mentioned elsewhere, come up with a recommended dir structure
under working
[9:39pm] HideyoImazu: regardless of the exact location, I think there need to be two kinds of
working directories as I said
[9:39pm] PeterThoeny: could be a "webs" sub-directory in each plugin's working dir, where
data s replicated based on web structure
[9:39pm] PeterThoeny: another option is to define a new type of working dir
[9:39pm] HideyoImazu: there are working data not suitable for replicating
[9:40pm] PeterThoeny: a working dir for webs, where a plugin can get a dir per root web
[9:40pm] HideyoImazu: PublishContrib result (can be big) and HeadLinesPlugin data are not
subject for mirroring
[9:41pm] HideyoImazu: while tagging data is permanent and need to be subject for mirroring
[9:42pm] PeterThoeny: i understand the need for two types of working data
[9:42pm] PeterThoeny: so, currently we have:
[9:42pm] PeterThoeny: getWorkArea( $pluginName ) -> $directorypath
[9:43pm] PeterThoeny: this could be declared as transient or non-web specific
[9:43pm] HideyoImazu: agreed
[9:43pm] PeterThoeny: we could define a new one:
[9:43pm] PeterThoeny: getWorkWebArea( $pluginName, $rootWeb ) -> $directorypath
[9:43pm] PeterThoeny: or just:
[9:44pm] PeterThoeny: getWorkWebArea( $pluginName ) -> $directorypath
[9:44pm] PeterThoeny: for web root
[9:45pm] PeterThoeny: or may be better call it: getWebWorkArea
[9:45pm] HideyoImazu: do you mean to introduce a new function getWorkWebArea()?
[9:45pm] PeterThoeny: yes
[9:46pm] HideyoImazu: how about introducing the optional second argument to getWorkArea() ?
[9:46pm] PeterThoeny: since the tagmeplugin has web specific data it could use that new call
[9:47pm] PeterThoeny: you mean like: getWorkArea( $pluginName, 0 or 1 ) ?
[9:48pm] PeterThoeny: with flag if web specific?
[9:48pm] HideyoImazu: no. getWorkArea($pluginName, $web)
[9:49pm] PeterThoeny: ah, yes
[9:49pm] PeterThoeny: one issue either way could be performance, traversing 1000 webs for
working data could be slow
[9:49pm] HideyoImazu: when do you need to traverse?
[9:50pm] PeterThoeny: for example when showing a tag cloud
[9:50pm] HideyoImazu: ah. that's not practical.
[9:51pm] PeterThoeny: it looks like this needs some more design
[9:51pm] HideyoImazu: so split tagging domain into top level webs
[9:51pm] HideyoImazu: we split tagging domains into top level webs
[9:52pm] PeterThoeny: that could work
[9:52pm] PeterThoeny: replication is only by top level web, not sub webs, right?
[9:52pm] HideyoImazu: i suppose that's the only practical way to use tagging on a twiki site
having thousands of webs
[9:52pm] HideyoImazu: correct
[9:54pm] PeterThoeny: so how shall we handle the proposal?
[9:55pm] HideyoImazu: the proposal is to add the way we do here into TagMePlugin
[9:55pm] PeterThoeny: meaning in pub?
[9:56pm] HideyoImazu: yes
[9:56pm] PeterThoeny: i am ok with this
[9:56pm] PeterThoeny: someone should though design a solid solution for plugin working data with
replication
[9:57pm] PeterThoeny: not urgent
[9:57pm] HideyoImazu: maybe yaojun or i should writhe a proposal about getWorkArea()
[9:57pm] PeterThoeny: yes
[9:57pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/RealTimeNotificationByMailerContrib
[9:57pm] PeterThoeny:  Feature Proposal: Real-time notification by MailerContrib - by hideyo-san
[9:58pm] PeterThoeny: i glanced over it and did not understand the details
[9:59pm] HideyoImazu: what do you think, peter?
[9:59pm] PeterThoeny: for one, real-time or batch notification should be per user, not per chnaged
page?
[9:59pm] HideyoImazu: to put it simply, introducing afterSaveHandler() doing real-time change
notification
[9:59pm] PeterThoeny: so, each user has a choice if real-time or batch notification?
[10:00pm] HideyoImazu: notification is per topic and attachment
[10:00pm] PeterThoeny: or a page owner decides for all users if real-time or batch?
[10:00pm] HideyoImazu: not quite
[10:01pm] HideyoImazu: when a topic is saved, the afterSaveHandler() is kicked
[10:01pm] HideyoImazu: it read WebPreferences and see who are subscribing to the topic.
[10:01pm] HideyoImazu: if there are users subscribing to the topic, it sends an email notification.
[10:02pm] HideyoImazu: WebNotify rather than WebPreferences
[10:02pm] PeterThoeny: concrete example:
[10:03pm] PeterThoeny: BreadSlicer topic has AmberSue and BertaCam as subscriber
[10:03pm] PeterThoeny: can amber signup for immediate, and berta for batch notification?
[10:04pm] HideyoImazu: that's possible by the following line on WebNotify
[10:05pm] HideyoImazu:   * %IF{"context notify_update or context notify_new" then="AmberSue: BreadSlicer"}%
[10:05pm] PeterThoeny: ok, understand
[10:06pm] HideyoImazu:   * %IF{"context mailnotify" then="BertaCam: BreadSlicer"}%
[10:06pm] PeterThoeny: but i think this is very technical, way to complicated for a sales person
or my mother
[10:07pm] HideyoImazu: I suppose most users are fine by real-time notification only
[10:07pm] PeterThoeny: in fact, i think the whole mail notify warrants a redesign with usability
in mind
[10:07pm] HideyoImazu: possibly so.
[10:08pm] PeterThoeny: side-note on real-time, consider issue of extra notifications on typo fix
[10:08pm] PeterThoeny: possible solution is to queue changes, and notify per topic with a 5 min
delay
[10:08pm] HideyoImazu: that's address by firing notification only when revision number is increased
[10:08pm] PeterThoeny: that way, follow-up edits are notified just once
[10:09pm] PeterThoeny: well, yes and no
[10:09pm] PeterThoeny: you will get notified just once, but on the first edit
[10:09pm] PeterThoeny: so you miss the final edit
[10:09pm] PeterThoeny: final edit notification
[10:09pm] HideyoImazu: yes
[10:10pm] PeterThoeny: so a queued notification with 5 min or so delay could solve that
[10:10pm] PeterThoeny: back to usability
[10:11pm] PeterThoeny: the existing webnotify is overly geekish and too complex for non-technical users
[10:11pm] PeterThoeny: that is why i kicked off idea
http://twiki.org/cgi-bin/view/Plugins/WatchAndSubscribePluginDev
[10:11pm] PeterThoeny: WatchAndSubscribePlugin
[10:11pm] PeterThoeny: i have now a bit a revised idea
[10:12pm] PeterThoeny: based on your proposal
[10:12pm] PeterThoeny: time check: +72 min
[10:12pm] PeterThoeny: how much longer?
[10:12pm] HideyoImazu: 30 - 40 min
[10:12pm] PeterThoeny: ok, let's try to keep it short
[10:13pm] PeterThoeny: internal spec aside, let's for a moment think of how the user interacts with
the machine
[10:14pm] PeterThoeny: with the plugin i proposed there are two new menu items / buttons to watch 
the page, and to subscribe for email notification, respectively
[10:14pm] PeterThoeny: now i think this is overkill too on ui
[10:14pm] PeterThoeny: much more simple:
[10:15pm] PeterThoeny: just one "watch this topic" menu item / button
[10:15pm] PeterThoeny: so there is a watch page to watch all page changes of interests, like in
mediawiki
[10:16pm] PeterThoeny: in addition, the user has a picklist to get notified by email in real-time,
in batch mode, or not get notified at all by email
[10:16pm] PeterThoeny: simple binary ui, reduces complexity
[10:17pm] PeterThoeny: reduces flexibility to (but steve jobs liked to do that too)
[10:17pm] PeterThoeny: power users can still use the webnotify
[10:18pm] HideyoImazu: will it be independent from webnotify?
[10:18pm] PeterThoeny: e.g. offer oth options, the old webnotify and the new watch
[10:18pm] PeterThoeny: "both options"
[10:18pm] PeterThoeny: we could actually consider retiring webnotify
[10:19pm] PeterThoeny: question is if it is ok to remove flexibility of wildcard subscribes
[10:20pm] HideyoImazu: there should be users depending on it
[10:20pm] PeterThoeny: one feature that should be considered adding if webnotify is retired is
to watch (and subscribe) a whole web
[10:21pm] PeterThoeny: this could be done in webhome
[10:22pm] PeterThoeny: the watch menu item in webhome could be labeled "watch the Foo web", for
all other topics in that web it could be "watch this topic"
[10:24pm] PeterThoeny: overall, what do you think about this ui?
[10:24pm] MahiroAndo: I like the new simple ui
[10:25pm] MahiroAndo: maybe it's also possible to support wildcard with this?
[10:25pm] HideyoImazu: let me see ...
[10:27pm] HideyoImazu: the UI looks good
[10:27pm] HideyoImazu: I wonder if it's possible to implement something like PreferencesPlugin
[10:27pm] PeterThoeny: ok, i propose to continue the discussion on the proposal topic
[10:28pm] HideyoImazu: I realized I need to run to a next meeting in a few min
[10:28pm] PeterThoeny: ok
[10:28pm] PeterThoeny: i'd like to quickly cover two more:
[10:28pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/ConditionalSkin
[10:28pm] PeterThoeny:  Feature Proposal: Conditional Skin based on group membership and other
criteria - by pth
[10:29pm] PeterThoeny: this is based on a request/question in support web on twiki.org
[10:29pm] PeterThoeny: i already have implemened on my machine
[10:29pm] PeterThoeny: simple
[10:29pm] PeterThoeny: thumbs up/down?
[10:29pm] HideyoImazu: up
[10:29pm] MahiroAndo: yes simple enough. ok by me
[10:30pm] PeterThoeny: ok, decided by release meeting
[10:31pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/EditorWithTWikiVariablesWizard
[10:31pm] PeterThoeny:  Feature Proposal: Editor with TWiki Variables Wizard  - by pth
[10:31pm] PeterThoeny: simple need
[10:31pm] PeterThoeny: but complicated to implement
[10:31pm] PeterThoeny: have you seen the wizard page?
[10:32pm] PeterThoeny: the wizard aready exists
[10:32pm] HideyoImazu: looking
[10:32pm] PeterThoeny: but tying it into raw edit and wysiwyg editor is a bit complex
[10:32pm] PeterThoeny: wizard is at
[10:32pm] PeterThoeny: http://develop.twiki.org/~twiki4/cgi-bin/view/TWiki/TWikiVariablesWizard
[10:33pm] HideyoImazu: it works on iPad
[10:33pm] PeterThoeny: i am using ajax
[10:33pm] PeterThoeny: yep, no flash
[10:33pm] HideyoImazu: it's worth pursuing, I suppose
[10:33pm] PeterThoeny: ok to implement?
[10:33pm] HideyoImazu: sure
[10:34pm] PeterThoeny: MahiroAndo-san?
[10:34pm] MahiroAndo: yes, ok
[10:34pm] PeterThoeny: thanks, decided by release meeting
[10:34pm] PeterThoeny: this is all i have
[10:34pm] PeterThoeny: we can skip bugs and extensions this time
[10:34pm] HideyoImazu: sorry, i need to run. ttyl
[10:35pm] PeterThoeny: ok, thanks HideyoImazu-san
[10:35pm] PeterThoeny: ---++ 4. Miscellaneous
[10:35pm] PeterThoeny: anything MahiroAndo-san?
[10:35pm] MahiroAndo: nothing from me
[10:35pm] PeterThoeny: ok, also nothing on my side
[10:36pm] PeterThoeny: thanks all!
[10:36pm] PeterThoeny: i'll post the logs and update the minutes
[10:36pm] PeterThoeny: ttyl
[10:36pm] MahiroAndo: cool. thanks very much!
[10:37pm] MahiroAndo: ttyl
[10:37pm]  MahiroAndo left the chat room.
[10:52pm]  HideyoImazu left the chat room. (Ping timeout: 245 seconds)