#666 Fully implement BrowserTabID

[Mark Grimshaw]

Since 6.4.0 (c. end 2020), the browserTabID functionality has been available (although described as experimental). Unlike standard server sessions, this feature uses browser sessions which means that each browser tab or window has its own sessions which means that various operations in WIKINDX can be separated from each other. Thus, different searches can be conducted in different browser tabs or two browser tabs can be used to enter different resources, and the form values will be correctly remembered for each in case of input error. This is very useful and no problems have been reported in the past few years.

Currently:

• BrowserTabId is disabled by default for new installations (under the Miscellaneous tab of Admin|Configure)
• WIKINDX pages using it must be opted in in the file BROWSERTABID.php.

Proposed changes:

• Enable BrowserTabID by default for new installations.
• Change to an opt out system on the understanding that most WIKINDX operations will benefit. Those that should be opted out include the main configuration page. Note that operations using browserTabID functionality must still code for that functionality—the difference is that the file BROWSERTABID.php will not need to edited to include that operation.

[Stéphane Aulery]

Hi Mark,

You know my opinion: a better design would remove the need to compartmentalize the session by tab using the browser while respecting the stateless aspect of HTTP. The future should adopt this way of working.

But as the saying goes, if I had more time I would have written a shorter letter. No objection to making this an opt-out option at this time.

Regards,

[Mark Grimshaw]

OK. At some point you will need to explain to me how it all will work in the future . . .

Mark

[Stéphane Aulery]

Of course, quick response is (a) a way to maintain session state with GET parameters in the case of a search for example, and (b) another stateless way of handling responses for regular forms.