Release Meeting: 20 Feb 2017

(08:01:02 AM) gac410: Hi everyone.   Good morning? ..    Ready to get started?
(08:03:23 AM) MichaelDaum: hi guys
(08:03:48 AM) jomo  entered the room.
(08:04:16 AM) gac410: light turnout so far.   I was hoping that Julian and Crawford would make it too.  They have proposals listed for 2.2
(08:04:40 AM) jomo: :D
(08:05:15 AM) gac410: Anyway,  I spent some time digging out incomplete Task items with commits but not ready to release,   as well as all the proposals for 2.2
(08:05:30 AM) gac410: So they are on the agenda:    https://foswiki.org/Development/ReleaseMeeting02x02_20170220
(08:06:31 AM) ***MichaelDaum looking at the list
(08:08:58 AM) MichaelDaum: we need to make sure that devs are still committed to work on their stuff 
(08:09:17 AM) MichaelDaum: it is a big pile of work
(08:09:28 AM) MichaelDaum: but good to see it all together on one page
(08:09:41 AM) MichaelDaum: some of it seem to be low hanging fruits
(08:09:49 AM) MichaelDaum: others bare a can of worms
(08:10:04 AM) gac410: y.   Last I knew Julian was still committed on the backlink stuff.    I think Lavr's proposals should go to "needs developer"
(08:10:04 AM) MichaelDaum: or are just more complicated to do
(08:10:10 AM) gac410: Y.   
(08:10:37 AM) MichaelDaum: which one is Kenneth's?
(08:11:13 AM) gac410: I've got to look.   Don't recall now.
(08:12:27 AM) gac410: Actually not on 2.2. list.  Add WORKINGDAYS to SSP,  and Treat Numbers as upper case in wikiwords
(08:12:38 AM) gac410: https://foswiki.org/Development/ReleasePlan
(08:12:48 AM) MichaelDaum: I see. yea. but they are not scheduled for 2.2
(08:13:08 AM) MichaelDaum: though I think it is fair to say Kenneth isnt on the project anymore
(08:13:11 AM) gac410: Right.   I must have dropped them at some point.
(08:13:30 AM) ***gac410 still not quite awake yet  
(08:13:48 AM) MichaelDaum: :)
(08:14:15 AM) gac410: yeah.   He came back for a bit after 2.0 was out to ream us over the EditRowPlugin and a few other things,   and then disappeared again.
(08:15:02 AM) MichaelDaum: let me edit those two FPs
(08:16:31 AM) MichaelDaum: I will switch it to needs dev
(08:16:42 AM) gac410: okay thanks.
(08:17:23 AM) gac410: Lets proceed down the tasks on the agenda.   maybe we can close or defer some of them
(08:18:45 AM) gac410: Item13481 - Crawford's template restructuring.   You and CDot both recently commented.    Close it and wait for the skin framework work?  
(08:19:35 AM) gac410: Also 12511 deprecated Jquery.metadata.  Another multi-release task.  
(08:19:50 AM) vrurg: Hi everybody!
(08:19:59 AM) gac410: If we commit but don't close, they never end up in the release notes.      Hi Vrurg
(08:20:22 AM) jomo: hi!
(08:20:26 AM) gac410: Hi jomo
(08:20:43 AM) MichaelDaum: gac410, true.
(08:20:48 AM) MichaelDaum: hi vrurg+ jomo
(08:21:35 AM) MichaelDaum: let me have a look at the current checkins of Item13481
(08:22:43 AM) gac410: Item14225 ... was a branch I started to try to make sense out of some of the preferences.  Micha, you didn't seem all that enthused ;)   Maybe I should just no-action and drop the branch
(08:22:54 AM) MichaelDaum: three: two of them are on JavaScriptFiles ... one is more a hijacking checkin
(08:24:04 AM) MichaelDaum: Item13481 should be closed. any additional actions on (a) the templates and/or (b) the JavaScriptFiles ... should be addressed in a separate task
(08:24:19 AM) gac410: Y   I think that makes sense.
(08:24:46 AM) MichaelDaum: any work on this area (templates, JavaScriptFiles) ... in the realm of 2.2 is more of the kind of keeping alive the current situation.
(08:25:41 AM) gac410: y.   I think anything that breaks simple Upgrade process should be deferred for "Major" release changes.
(08:26:11 AM) MichaelDaum: we arent ready to revamp templates, consolidate the javascript framework, reworking  Foswiki::UI interacting with the template systems
(08:26:30 AM) gac410: y.   That's a huge effort
(08:27:22 AM) MichaelDaum: there are a couple of preliminary work that we need to do before we can rewrite the tmpl system: we need to move functions from Foswiki::UI into the Meta or Store layer.
(08:27:46 AM) MichaelDaum: ... the Registration subsystem etc.
(08:28:19 AM) MichaelDaum: there is too much good code in there which can't be reused elsewhere, other than coming via Foswiki::UI
(08:28:25 AM) MichaelDaum: e.g. merging forms n such
(08:29:14 AM) gac410: Ug.   I'm not sure where Registration really belongs.  I'm not sure Meta or Store would be right either.   Maybe a new Foswiki::Registration class or something
(08:29:33 AM) MichaelDaum: anyway. we need to break this down into manageable chunks that make sense.
(08:29:40 AM) gac410: y.
(08:30:26 AM) MichaelDaum: one of my all time favorite of sins is pseudo macros being used in templates
(08:30:58 AM) gac410: Back on tasks.   Item14023 is actually ready to merge.   I stripped out all of the Foswiki::Net fallback code, and everything seems to work fine with LWP.  
(08:31:00 AM) MichaelDaum: e.g. %REVISONS
(08:31:10 AM) gac410: Y,   Those template tokens are really ugly.
(08:31:59 AM) gac410: Totally screws up any concept of rendering order,  as they look like macros but are not.  
(08:32:56 AM) gac410: Item14003 - Scrapping the Foswiki::Address code   was Julian's work.   I think he should get that done for 2.2
(08:33:10 AM) ***MichaelDaum closed Item13481
(08:33:17 AM) gac410: thanks
(08:33:33 AM) MichaelDaum: let me have a look at Item14023
(08:34:13 AM) gac410: It was pretty simple.   Deleting code - I'm good at that  ;)  
(08:34:38 AM) MichaelDaum: awesome. this will ease AddNoProxyFeature a lot. please merge. 
(08:36:29 AM) gac410: will do
(08:38:05 AM) gac410: The next 3 tasks  (one line -  starts with 9790)   is restructuring bulk registration.  That's probably 90% done.  I just need to review wtf I actually did and polish it up.
(08:38:08 AM) MichaelDaum: what's the feature request that brought us Foswiki::Address .... (wrt Item14003)
(08:38:36 AM) gac410: That was done by PaulHarvey a very long time ago.   As part of his & Sven's  Mongo work iirc.
(08:38:55 AM) gac410: To centralize all parsing of Web/Topic/Attachment addressing.
(08:39:14 AM) gac410: and represent it as an object
(08:39:41 AM) gac410: It has some nice unit tests,  but isn't really used by core
(08:40:40 AM) MichaelDaum: I see. Dead code.
(08:40:44 AM) gac410: Not sure it was ever a feature vs. a code reorganizing  
(08:40:45 AM) MichaelDaum: too bad
(08:40:58 AM) gac410: Probably worth keeping around,  but needs work.
(08:41:17 AM) MichaelDaum: looking at the checkin on Item14003 ... https://github.com/foswiki/distro/commit/ee0fc4268eb5
(08:41:53 AM) MichaelDaum: it seems to remove it mostly in bogus places ... however there is one questionable change in there: it removes Foswiki::Meta::type()
(08:42:42 AM) MichaelDaum: this method is not directly related to Foswiki::Address
(08:43:00 AM) gac410: If Julian removed it, it was probably never actually used,  other than by Foswiki::Address
(08:43:09 AM) MichaelDaum: however as Foswiki::Meta - as Foswiki::Func - is a public api, we need to preserve it presumably
(08:44:26 AM) gac410: y.   It does seem useful,   but master is running fine without it,  so probably not used.
(08:44:30 AM) MichaelDaum: not a beauty of code, even incomplete.
(08:45:52 AM) gac410: y,  looks pretty bogus actually.    Dates from when everyone was just checking stuff into "trunk"  and would get around to it later.
(08:46:01 AM) ***MichaelDaum added a comment for Julian
(08:46:37 AM) gac410: Kinda like the code that allows you to QUERY all the original topic info,  creator, createdate, ...    Documented but never implemented.
(08:47:00 AM) MichaelDaum: you mean Foswiki::Address?
(08:47:25 AM) gac410: no  the Meta->type()    Incomplete implementation. 
(08:48:06 AM) MichaelDaum: well, it returns "topic", "webpath" or undef.
(08:48:39 AM) gac410: i removed the pseudo-meta documentation from QUERY in one of the last patches.    and there is also the bogus dataform types in configure that is never used anywhere.  
(08:49:28 AM) MichaelDaum: okay so release branches still have F::M::type(), master doesnt
(08:49:38 AM) gac410: This is all cleanup stuff from the 1.2 nightmare where everyone was just developing in master.  
(08:50:02 AM) gac410: Y.    I guess someone could be using it in an extension.  :(
(08:50:30 AM) MichaelDaum: I doubt it, but there is a chance.
(08:51:31 AM) gac410: Maybe it should go back into master but have someone actually complete the implementation?   IDK    I'd still lean toward eliminate it.
(08:52:01 AM) gac410: Wish Julian was here.  He spent more time on this stuff
(08:53:43 AM) MichaelDaum: this one introduced it: https://github.com/foswiki/distro/commit/f2297f8c21ad1aefaa0b1d442c46719d7102a764
(08:55:11 AM) MichaelDaum: this method is highly inefficient also
(08:55:53 AM) MichaelDaum: lets assume extensions do not load $meta objects for webs nor for the $root (which type() doesnt cover btw)
(08:56:12 AM) MichaelDaum: most extensions load $meta objs for topics, nothing else.
(08:56:39 AM) MichaelDaum: arguing this way, there barely is a need for type()
(08:57:27 AM) gac410: y.   I think Julian was right to scrape out some of this cruft
(08:58:10 AM) MichaelDaum: F::M itself would rather do an "if defined $this->{_topic}" ... rather than if defined($this->type()) && $this->type() eq 'topic'
(08:59:14 AM) gac410: y   Internal to F:M no need to use functions vs accessing internal data
(09:00:03 AM) MichaelDaum: lets not reintroduce it to master. 
(09:00:27 AM) gac410: It appears as though that commit f2297...   has been revised to work without the type() call.  so y.     scrap it.
(09:01:09 AM) MichaelDaum: I am going to close Item14003 then
(09:01:24 AM) MichaelDaum: no erm. waiting for release.
(09:01:51 AM) gac410: y.  
(09:02:10 AM) gac410: I'll set Target & Released in so we don't lose it.
(09:02:54 AM) gac410: Target "minor"   Released-in  2.2.0   if you would...
(09:02:59 AM) MichaelDaum: done
(09:03:04 AM) gac410: ty
(09:05:05 AM) gac410: The line after 14003 is in my court.   I was reworking bulk registration to have it use a view template, and make it much easier to use.     I just don't recall where I left off.
(09:06:19 AM) MichaelDaum: hehe. know that feeling.
(09:06:24 AM) gac410: Okay  Item14023 has been merged.
(09:08:09 AM) gac410: Item10149 is a performance issue.   No idea what really needs to be done here ... Commits only document that performance sucks 
(09:10:33 AM) gac410: Item12263  I have no idea.   It got partial fix in 1.1.6 
(09:11:37 AM) gac410: MichaelDaum said "The real fix would be to pass a user object."   which puts this into a boil-the-ocean category.  :(
(09:12:24 AM) MichaelDaum: y
(09:12:53 AM) MichaelDaum: meanwhile oceans are already boiled ... 
(09:13:19 AM) MichaelDaum: I have loads of other problems with all of the user mapping code
(09:13:55 AM) ***gac410 hates to go poking at this hornets nest.  Tempted to set to Needs Developer,  until the user mapping code gets it's rewrite  ... someday  
(09:14:09 AM) MichaelDaum: let me comment on Item12263 indirectly ... with yet another bad bug buried in the design of all this code
(09:14:38 AM) MichaelDaum: I just recently moved a client to active directory using ldap contrib
(09:14:58 AM) MichaelDaum: it requires that {AllowLoginNames} must be switched on
(09:15:12 AM) MichaelDaum: this changes cUIDs too
(09:16:12 AM) gac410: y.   Which probaly breaks all the old TOPICINFO meta
(09:16:14 AM) MichaelDaum: which means: the store now has got different kinds of authorship in its store history
(09:16:19 AM) gac410: yup
(09:16:33 AM) MichaelDaum: right. especially loading an old rev will start the problems.
(09:16:49 AM) gac410: The cUID mess really is a lurking disaster.  
(09:17:12 AM) gac410: And the indeterminate underscore encoding.  
(09:17:18 AM) MichaelDaum: why: it goes via Foswiki::Users .... which has got ... surprise ... an internal cache of its own. While passing user mappings thru its internals it keeps record which ids go together .
(09:17:36 AM) MichaelDaum: ^why^<del>why</del>^
(09:18:18 AM) MichaelDaum: so loading an old rev of a topic will _pollute_ the internal user mapping cache in Foswiki::Users ...and break any further calls to the user apis
(09:18:36 AM) gac410: ugh.  That's even worses
(09:19:38 AM) MichaelDaum: this all given that we have loads of login names that have dots or underscores in it ... 
(09:20:31 AM) MichaelDaum: Item12263 is relatively harmless compared to this flaw
(09:21:17 AM) gac410: Item11624.   I think I'm just going to no-action that one.   Sven did some major work and then said "I didn't mean to commit this yet though, as I want to write unit tests for it. - work in progress for 1.1.5."     So I reverted it to get 1.1.5 out the door :P
(09:21:43 AM) gac410: It's not a bug that I can see,  so I think just getting it off the plate would be best.
(09:22:06 AM) gac410: I was thinking it had commits,  but they are all reversed. So  NOP
(09:24:51 AM) MichaelDaum: ok
(09:25:16 AM) MichaelDaum: I'll close Item12263. as far as I see things that we can fix have already been fixed ... and released.
(09:25:29 AM) gac410: So 12263 ... So we don't trip over it and re-review this yet again?    Should we No-action,   Ah... good.  
(09:25:30 AM) MichaelDaum: kinda lipstick fixes
(09:26:29 AM) gac410: Basically if a task has checkins against master,  and is not closed,   I'm going to "re-discover" it all over again when I do the commit reviews for incomplete work and put us through this hell again.
(09:31:10 AM) gac410: Onto the incomplete features.   I wish crawford was here.  He's done a lot of work on some of them and they sit un-merged / incomplete.
(09:32:56 AM) gac410: Item13905 is https://foswiki.org/Development/ImproveSupportForComments     And got into some kinda discussion hell.  
(09:33:07 AM) gac410: It implements  #{  }#   as a new comment type.
(09:34:48 AM) MichaelDaum: he still has got time to finish it
(09:35:38 AM) gac410: It actually seems to be complete... with unit tests and everything.  It's more the discussion of the proposal that broke down
(09:36:53 AM) MichaelDaum: okay
(09:37:13 AM) MichaelDaum: well we don't have to rush it. we are still at the beginning of this dev cycle
(09:37:18 AM) gac410: I'll table that one for the next time we see CDot.  
(09:37:26 AM) MichaelDaum: k
(09:38:10 AM) gac410: Then next proposa ... ConfigurableCookeiNamesAndPaths.  Is mostly done in master due to our cookie/blog issues.  But I think implementing the new JQuery cookie code would make sense there.
(09:38:31 AM) gac410: we still have some cookies that are not handled consistently.
(09:39:57 AM) MichaelDaum: I see. yet still the feature proposal itself is implemented, isnt it
(09:40:09 AM) MichaelDaum: i.e. for session cookies
(09:40:23 AM) gac410: For session cookies yes. 
(09:40:30 AM) MichaelDaum: and twisty cookies
(09:41:02 AM) gac410: strikeone and twisty are incomplete, I don't believe they handle the path. Only the domain
(09:41:17 AM) gac410: We are not using path.  So we get away with the incomplete fix
(09:41:25 AM) gac410: moment... afk
(09:42:21 AM) MichaelDaum: things left to do in that area:
(09:42:31 AM) MichaelDaum: (1) upgrade to newer jquery cookie impl
(09:42:58 AM) MichaelDaum: (2) this comes with an api change of its own for any jquery plugin that uses it
(09:43:11 AM) MichaelDaum: (3) alter strikeone and twisty to use jquery.cookie
(09:44:15 AM) MichaelDaum: (4) move any special PREFS code out of the core of related JavaScriptFiles and move it into jquery.foswiki ... which may interact with jquery.cookie as required.
(09:44:38 AM) MichaelDaum: (5) and so on
(09:44:41 AM) gac410: y
(09:45:13 AM) gac410: Ah ha... CDot just connected.  
(09:46:06 AM) cdot [~crawford@foswiki/developer/cdot] entered the room.
(09:46:26 AM) gac410: MichaelDaum:   Do you want to tackle any of the javascript side sometime between now and April freeze?
(09:46:26 AM) ***cdot has emerged after the week from hell
(09:46:58 AM) gac410: Welcome back.  Hopefully not too many burns from the hellfiires  
(09:47:00 AM) MichaelDaum: gac410, yes definitely.
(09:47:37 AM) gac410: Okay MichaelDaum great thanks.   the js side definitely falls outside of my comfort zone for sure.
(09:48:04 AM) cdot: link to the task you are discussing?
(09:48:21 AM) gac410: CDot ... https://foswiki.org/Development/ReleaseMeeting02x02_20170220#Implementation_underway
(09:48:41 AM) cdot: thx
(09:49:06 AM) gac410: first item.   ImproveSupportForComments.    You implemented #{ }#   in Item13905   but rather got stuck in limbo...  
(09:49:24 AM) gac410: My impression it that it's probably ready to merge  except for discussion hell.
(09:51:41 AM) cdot: The people most likely to make use of it are template topic developers. And I got 0 feedback, so wasn't motivated to take it further.
(09:52:08 AM) cdot: If MichaelDaum / jast think it's worthwhile, then maybe it's worth doing.
(09:52:29 AM) cdot: otherwise, just drop the branch.
(09:52:31 AM) MichaelDaum: it is probably more usefull for docuing inline wiki apps
(09:53:03 AM) cdot: it *should* be useful for doccing *anything* - but seems doc is a dirty word.
(09:53:10 AM) MichaelDaum: template topics are better off using %{ }% already
(09:53:27 AM) MichaelDaum: only problem I see is confused users
(09:53:42 AM) cdot: maybe we should just merge it, and see what happens >:-)
(09:54:13 AM) MichaelDaum: %{..}, #{..}#, <!-- ... -->, verbatim class=foswikiHidden> .../verbatim>, template-only section, ... you name it
(09:54:18 AM) gac410: Well the proposal had a lot of discussion,  just not productive.     So there certainly was some interest  
(09:54:46 AM) MichaelDaum: y
(09:55:19 AM) MichaelDaum: cdot, could you explain to me  - a wiki app newbie - when to use %{ ...}% and when #{ ... }# 
(09:55:48 AM) cdot: right now, no. Reading what is writ.
(09:56:12 AM) MichaelDaum: something like "make commenting great again"
(09:57:41 AM) cdot: I think it's something like "Use %{}% in skin templates, and #{}# everywhere else"
(09:58:24 AM) MichaelDaum: this is what worries me most about this particular feature. not that it is a bad idea. just that it is adding to a stack of other not-bad-could-be-worse ideas.
(09:58:53 AM) cdot: indeed. So we can do it, or do nothing. Do nothing is easier.
(09:59:12 AM) MichaelDaum: point is. what do we _want_.
(09:59:38 AM) cdot: everything on the menu. All in a bucket. With an egg on top. ;-)
(10:00:55 AM) MichaelDaum: as long as we can't explain it properly to Aunt Tiffie, I am leaning towards holding it back.
(10:01:09 AM) gac410: I think the issue is that this syntax #{ }#  seems really useful,  but it's confusing when to use %{ vs #{   
(10:01:40 AM) gac410: And +1 ... without being able to explain why/when to use it,  it's hard to find the real need.
(10:02:10 AM) cdot: Not really. I just explained it; %{ in skin templates, #{ otherwise. To simplify it, deprecate %{ in skin templates and implement #{ there as well.
(10:02:46 AM) cdot: multiple syntaxes only there because I made a bad (lazy) choice in skin templates of %{
(10:02:59 AM) cdot: chance to correct that error here.
(10:03:43 AM) MichaelDaum: what about %{&lt;verbatim>}% ...%{&lt;/verbatim>}% in template topics
(10:04:18 AM) MichaelDaum: same question for #{ verbatims }# ...
(10:04:43 AM) cdot: that doesn't do anything *now*, does it?
(10:04:55 AM) MichaelDaum: why not
(10:04:57 AM) cdot: or do you mean "skin" template topics?
(10:05:08 AM) gac410: skin template topics.  
(10:05:10 AM) ***cdot is never sure what "template" means
(10:05:37 AM) cdot: ok, skin template topics are skin templates, just stored in topics. So %{ deprecated will continue to work there
(10:05:45 AM) MichaelDaum: https://demo.michaeldaumconsulting.com/bin/view/Applications/WikiTopicViewTemplate?skin=pattern
(10:06:02 AM) gac410: y,  In another of your proposals... I snuck in the proposal that we start calling topic tempates   topic prototypes   :P
(10:06:34 AM) MichaelDaum: TopicView is what I call them
(10:07:05 AM) cdot: saw that, considered getting a hood out from Chicago to take you out, decided it wasn't worth the $50 
(10:07:30 AM) gac410: :P
(10:07:48 AM) cdot: whatever. That terminology problem is way bigger than the %{ #{ debate.
(10:08:20 AM) gac410: our overloading of the term template is probably one of the most confusing part of foswiki to the newbie.  But never mind.  
(10:08:23 AM) cdot: I'm easy about what happens with that comment syntax. I just thought it would be good to have one.
(10:09:28 AM) MichaelDaum: my feeling is that %{&lt;verbatim>}% ... %{&lt;/verbatim>}% will affect the contained content whereas the same with #{ &lt;verbatim> does not
(10:09:30 AM) gac410: Okay.   Is there any *timing* difference between %{ and #{   or are they both removed very early.      Can I use #{ to comment in a topic but have it redacted from the generated html?
(10:09:52 AM) gac410: Exactly  that to me is VERY important distinction.
(10:10:09 AM) cdot: OIC what you are doing with %{ there, MichaelDaum. OK, so I didn't particularly intend that. 
(10:10:35 AM) cdot: gac410: #{ should be removed *at the first possible time* so before any other rendering or processing of the content.
(10:11:07 AM) cdot: Pretty much at topic/template read-from-disk time.
(10:11:09 AM) gac410: So   %{ some content }% i ignored when processing a template,   but becomes  simply  "some content"  when viewing the template as a topic.
(10:11:24 AM) cdot: yes, that's how MichaelDaum is using it.
(10:11:25 AM) MichaelDaum: so #{ are processed early, then all the rest in the middle including verbatim and finally %{ are patched out just at the very end
(10:11:27 AM) gac410: vs.   #{ some content }#   is completely removed
(10:11:43 AM) gac410: Right... So this is indeed a benefit IMO
(10:11:52 AM) gac410: And both syntaxes are needed
(10:12:01 AM) cdot: unfortunately it would seem so.
(10:13:19 AM) gac410: So I'd vote to merge  that one.   assuming docs are complete.   Given we've gotten this confused,   I think the docs may need some examples on when to use.
(10:18:03 AM) MichaelDaum: +1
(10:18:52 AM) gac410: So cdot,  while you are here,  https://foswiki.org/Development/SupportAllMacrosInTemplateTopics ... Item13909 is another one of yours.   But needs a change to use EXPAND: syntax. 
(10:18:52 AM) gac410: Do you want to finish that one off,   or should one of us make the change and merge?
(10:19:59 AM) cdot: I'd better do the changes. The branch needs a merge out first, and that might confuse things. And I'm probably the bext person to write the doc.
(10:20:20 AM) cdot: Will give you a shout when it's ready to merge into trunk (or just watch)
(10:20:51 AM) gac410: Do you really need to do a merge out first?    I think simple merge in usually works unless there were conflicts
(10:22:41 AM) gac410: Okay.   Michael,   regarding https://foswiki.org/Development/MoveQueryPathParsingIntoFoswikiRequest ... You made some changes to Item14033 branch after it had been merged into master.   And I had changed master for some of the issues.   So it got badly conflicted.
(10:23:04 AM) gac410: Have you been testing with master?  And is it usable as is?   The conflicts will be painful to figure out.
(10:23:50 AM) gac410: I rewrote some of the code while working with vrurg on his object code where he found issues with the feature, and then pulled that back into master.
(10:28:05 AM) MichaelDaum: gac410, this work has been quite shaking things. it basically changed the behavior of jsonrpc
(10:28:39 AM) MichaelDaum: the hard lesson to learn is: they both aren't that compatibile, the way to parse the request and init the session.
(10:29:01 AM) vrurg: I have to run. It's not much help from me today anyway. Brief report: zero development. 9th wave of problems like a bug in vmware wiping out my personal server at the very moment when backups were deleted. Hope to get more for the next meeting.
(10:29:18 AM) MichaelDaum: the biggest problem is that the json request obj might hold a topic attribute that changes the web.topic location of the session
(10:29:29 AM) gac410: The real problem I have/had is that there are no testcases at all for jsonrpc.   I wrote some,  and depended greatly on configure.
(10:29:32 AM) MichaelDaum: as well as multi params
(10:29:50 AM) gac410: vrurg:    Okay.    That sure sucks.    good luck recovering.
(10:30:22 AM) gac410: MichaelDaum: The json request obj topic attribut should be correctly picked up now.   That was the whole point of the change.
(10:30:50 AM) vrurg: Almost done it. But a week was wasted. Ok, see you later!
(10:30:51 AM) MichaelDaum: while the apis in foswiki::request and json::request might be called similarly, they don't do the same under all circumstances
(10:31:21 AM) gac410: That was the whole point of the restructuring.  To get the json objec parsed really early so that the initial topic would be correclty set.
(10:31:35 AM) MichaelDaum: next is the handling of POSTDATA
(10:32:17 AM) MichaelDaum: we need to be able to post data to a jsonrpc
(10:32:29 AM) MichaelDaum: without it ending up in %QUERYSTRING and the like
(10:33:13 AM) gac410: That should all be working fine.
(10:33:24 AM) gac410: But without any possiblity of testing,  .... 
(10:33:34 AM) MichaelDaum: I've got a patch to master that is small enough and seems to fix the issues I had. 
(10:34:39 AM) MichaelDaum: what I totally forgot about before your initiative started is forms that are posted to a jsonrpc. .... and then process it as if it was a jsonrpc call
(10:34:56 AM) gac410: At this point the fixes do need to go into master.  Reverting will be really hell.  Esp. since all of this has been incorporated into vrurg's object branches
(10:35:06 AM) MichaelDaum: so both way need support: <form action=...jsonrpc> ... as well as doing it the javascript way ... $.jsonrpc()
(10:36:22 AM) gac410: the unit tests I wrote DO test POSTDATA
(10:36:42 AM) MichaelDaum: I wonder why PerlWeekly ignored our release ...
(10:36:55 AM) gac410: JsonrpcTests::test_simple_postdata   
(10:37:14 AM) gac410: btw   did you tweet it?    I don't have a twitter account
(10:37:23 AM) MichaelDaum: and they retweeted it
(10:38:37 AM) MichaelDaum: yet still their latest  PerlWeekly prefers other kind of infos ... more on little programming tricks. "How I got three errors into one line of code"
(10:38:49 AM) MichaelDaum: ... says it all
(10:39:13 AM) gac410: well given perls old contests for obfsuscated oneline programs,  that makes sense ;)
(10:40:16 AM) gac410: One more big feature we need to think about is https://foswiki.org/Development/DependenciesFreedom     This branch could be merged into master
(10:40:17 AM) MichaelDaum: too bad, all this. I enjoyed sharing the cebit booth with Gabor Szabo in 2012.
(10:40:50 AM) gac410: vrurg did a lot of work to make cpan stuff "just work"   But I have not tested it.   
(10:41:18 AM) ***gac410 gets scared by magic and we've had major foobars with prior attempts at automagic cpan
(10:42:54 AM) MichaelDaum: let me take a trumpish stance: I don't have my glasses on ... too long ... wont read. what is it?
(10:43:19 AM) gac410: If core detects missing dependency,  it magically adds it    I don't recall how
(10:43:54 AM) MichaelDaum: as part of calling configure I guess
(10:45:48 AM) gac410: Actually right at the top.   If you bin/view and are missing anything it can install them.   iirc
(10:45:55 AM) gac410: I do need to review it I guess
(10:46:01 AM) gac410: I've not tested it.
(10:46:30 AM) MichaelDaum: why is that
(10:46:43 AM) MichaelDaum: why put it into a critical code path
(10:47:04 AM) MichaelDaum: is it in BEGIN or later
(10:47:39 AM) gac410: I don't recall now.   I need to go review.   And while looking at commits,  there is some of the object code there so I guess we cannot merge in the current state.
(10:47:50 AM) gac410: Maybe best to push to 3.0 
(10:48:06 AM) gac410: we have enough other stuff to deal with
(10:48:20 AM) MichaelDaum: lets pick up this discussion on the next meeting
(10:48:31 AM) MichaelDaum: vrurg isnt here anyway to comment
(10:48:59 AM) gac410: y.      Over the next two weeks   if we could get some of the   Implementation underway  items merged & closed that wouild be great. 
(10:49:26 AM) gac410: Pick up next meeting with the "  In Release Plan - no work"  category
(10:49:46 AM) gac410: Thanks everyone!   
(10:49:48 AM) gac410: Great meeting
(10:49:53 AM) MichaelDaum: alright. I've got a next meeting in 10 mins. 
(10:50:28 AM) MichaelDaum: see you on the other side
(10:51:34 AM) gac410: see you .... Thanks again.