Item13087: Configure interface performs too many jsonrpc calls

• only load the current "tab" ... not all of them at first load
• batch multiple things to be checked into one RPC

See also discussion at Development.ReleaseMeeting01x02_20141013.

-- MichaelDaum - 10 Nov 2014

No no no... We need all the tabs checked on initial load. Otherwise you never find errors in hidden tabs. Absolutely no way to I want to have to click every tab, including expert hidden tabs, to get the checkers to run.

-- GeorgeClark - 10 Nov 2014

George, do you agree that there are too many jsonrpc calls? There are two solutions as I listed above.

See also my comments on Item13088 about the scope of changes that a user is going to commit.

-- MichaelDaum - 11 Nov 2014

I'm not sure this is correct. I've run a a few traces, and it looks like there are 4 posts to jsonrpc:

• getspec: loads the schema
• getspec: For the 1st tab, loads the General Path Settings tab
• check_current_value: check all settings (batched across all tabs)
• check_current_value: check general path settings (current tab)

This doesn't seem all that excessive to me. Maybe there is a way to combine some of these, but it doesn't seem worth it to me. I was concerned that it was calling a jsonrpc for each tab across the whole hierarchy. That doesn't seem to be the case.

Leaving this "New" and think it could be set to "No action necessary"

-- GeorgeClark - 17 Nov 2014

Michael, could you either confirm or no-action this? Are the 4 POSTs mentioned above what you consider excessive? From what I can tell they are batched together. Crawford, do you agree?

-- GeorgeClark - 23 Dec 2014

There are too many RPC calls, but not in the way Michael identifies. When you open the root tab, the entire hierarchy is checked. This check shouldn't need to be repeated when a sub-tab is opened but it is. The reason is that the initial check throws away a lot of the detail of the root check - it should cache it in the DOM, but there is no-where to hang the information until after the tab is loaded (which requires a getspec that isn't performed until the tab is opened. So yes, too many RPC calls are made, but it's a lot of work to improve on so I felt the tradeoff wa worth it.

-- CrawfordCurrie - 27 Dec 2014

Why store it in the DOM? Make it a local property of configure.

-- MichaelDaum - 27 Dec 2014

What I mean is: caching data doesn't require them to be stored in the DOM view. Data should simply be cached as a property of the service function used internally.

-- MichaelDaum - 07 Jan 2015

It's still floating around somewhere in the browser. Yes, it could be done that way.

-- CrawfordCurrie - 20 Jan 2015

Not really floating. The cache would basically be stored in memory, assigned to some javascript variable.

-- MichaelDaum - 21 Jan 2015

Commenting is disabled while not logged in