Hi OC, This is a very complex question with many possibles solutions having their owns problems...
If you use auto-magic WO with auto generated url using actions bindings with complex pages, there is no safe way to support multiple concurrent tab or windows in the same browser for these components. You would need an infinite page cache to make sure the last used tab is not forgotten before its next interaction. If you can limit the contents allowed in "other" tabs, it is possible to have a safe solution by using only direct actions inside those allowed components and keep the main app in the easy for dev mode. I developed a way to detect other tab usage and bloc them (the last opened deactivate other one). If the user comme back to a previous one, an alert id displayed and it is possible to continue there but you are back to the app home page. This is mostly to help when they close the active tab to keep the active session. All session based server frameworks lock the session during a request to ensure the session data is coherent, this limit the processing to 1 concurrent request per session on the server. You can almost eliminate the pause effect for long requests by using LongResponsePage or other means to display a work in progress in a background thread. You start the long request in background and create an auto refreshed progress page and return it to the browser quickly, If you want to go full concurrent requests for a user, you need to get rid of the session and page cache, this can represent a huge amount of work, it would probably be better to switch to a full page JS frameworks for the UI but even those does not like multiple tabs with complex apps... I try to adjust my UI to reduce the need of those multiple tabs or windows, this is by far the easiest way to help users. Regards, Samuel > Le 19 août 2024 à 09:25, ocs--- via Webobjects-dev > <webobjects-dev@lists.apple.com> a écrit : > > Hi there, > > looks like the main cause of those overlapping R/Rs which we ar clashing with > lately is that some users just open their session in more windows or tabs, > and work concurrently in those. Sigh. > > It's self-evident why it is a pretty bad idea from the technical POV, but I > am afraid we can't explain it to plain users. Worse, if we found a way to > prevent that (offhand, I am not sure whether it is technically possible, but > even if so), I am afraid the users would complain that they simply insist on > this terrible approach. > > Now though they complain some operations are “inexplicably” slow: “I > understand that operation A which I've launched in one of my windows is > complicated and thus takes many seconds, that's OK. But at the same moment > I've launched an operation B in another of my windows; operation B is trivial > and should be lightning fast, but it took an eternity! Fix your broken > application!“ > > Well you twit, op B took an eternity since it first waited many seconds until > the slow op A you yourself launched in the same session finished; after that, > A took about 100 ms of its own time. But this kind of explanation would not > do with plain users at all :( > > Could anybody see any practical solution? > > Note please that making _all_ R/R lightning fast is practically impossible > (we would have to refactor too heavily, not an option in a near future). > Besides I am afraid even if we somehow succeeded to make all R/R reliably > belong a second or so, they would still launch ten second-long operations in > ten windows plus one 100 ms in another, and then complain that the last one > took seconds too :( > > At this moment about the only solution very ugly work-around I can think of > would be to choose a couple of the trivial operations whose speed the users > consider most important, and re-write them without session (they would still > need to work with the session ID, but important things like the current user > etc. would have to be cached in the application in some kind of static map > without using the Session instance at all). Sigh. Darn complex, but still > worlds easier than attempting to make _all_ R/Rs 100ms-or-less... > > Any better idea? > > Thanks and all the best, > OC > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to sam...@samkar.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
