[wp-trac] [WordPress Trac] #64696: Real time collboration effectively disables persistent post caches while anyone edits a post

[WordPress Trac]

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by dmsnell):

 > I haven't heard any proposed alternate defaults for the polling
 intervals.

 @czarate was long-polling explored? my proposed alternative is //no
 polling intervals//. even without the optimization of holding a single-
 writer process, that should still eliminate the network activity even
 though it wouldn’t also eliminate the database activity.

 > However, we still frequently poll for updates from the server because we
 don't know when other remote peers have updated the post in their
 editors…We also poll for awareness state

 Sorry for my misunderstanding. The discussion led me to believe that we
 are still sending pings to the server and updating `post_meta` for
 awareness even when the cursor hasn’t moved; literally when the human
 editor is sitting idle with the block editor open on the post.

 > With collaborators in the room, I don't think we'd want to do so to a
 heartbeat frequency…Are you able to post some thoughts there?

 @peterwilsoncc I will take a look. My questions here though are not about
 //how many milliseconds between polling// but rather //event-based
 polling// and listening for updates. Even with an HTTP “polling” API we
 should be able to have two-way pseudo-realtime event streaming between the
 server and each client, eliminating the need for all this noise.

 The tradeoff is that these approaches require a persistent PHP process on
 the server per open editor session (without any further optimizations).
 Maybe that was dismissed because of an expectation for sites with
 thousands of concurrent editing sessions…?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:76>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform