I think I have a branch of code locally that started looking at how to generate JSON Patch fragments from the history component. That seemed to be the most sensible way to approach this - as it should be possible to apply patches in a well defined order (and also has some well-known algorithms for resolving out-of-order merges).

My assumption was to serialize the editing actions by communicating with runtime APIs.
Your suggestion using JSON patch may be useful if we deal with it as client-side merge process. However, I feel it will be difficult to guarantee that multiple clients will get the same editing results.

JSON Patch is one possible format - but the key is the history component would be the central place to know that a change has happened, and that change should be communicated to other editors. When the other editors receive the details of that event, they need to apply them to the local configuration - translating the event from whatever format it is in back into whatever modification to internal state in the editor is needed.

I agree. My assumption is that the runtime manages the edit histories to keep the order consistent for all clients.

Shifting the edit history to the runtime is a major change to how the editor works. We'd need to see a lot more detail on how you think that would work. Resolving concurrent edit state between multiple parties is a very complex task - there are countless research papers on the topic. This is the part that I'm most interested in - we cannot underestimate the difficulty in getting it right.

For example, how do you resolve conflicting changes to the same resource. How do you manage ordering of changes. How do you manage undoing a change.

But this still remains an academic conversation untill we under stand how we handle the deploy button issue.

Thanks for your comment. I have updated the design document.

Regarding the issue of the deploy button, I would like to suggest a method that all users to save the fix and then deploy it.
Also, for edit action conflicts, I would like to suggest serialized application of operations based on atomic application of each edit actions.

Yes - this would have to be an opt-in feature.

I also wonder whether this should be provided by a plugin rather than part of the core. It would require some additional APIs to be exposed in core for sure, but it may be a cleaner approach - particular for those who embed Node-RED and don't want this type of functionality at all.

Yes. Various event extensions will be required in Node-RED side, but I think it can be implemented as a plugin.

Being able to lock tabs comes up in other contexts. For example, restricting who can edit certain flows based on user name/role. So I think there is value in exploring this approach as I think it will help other use cases.

There are plenty of difficulties around managing the locked state - and how you handle the case when someone wanders off for a long weekend, forgetting they have left a tab locked. And you do describe some possible ways to manage that.

As you wrote, the ability to limit flow editing may be useful in team development.
I think long-term locking issues can be resolved by arrangements within the team in most cases. Ancient revision control systems such as CVS used such means.
However, considering the occurrence of locking problem, it seems that forced unlock feature may be necessary.

It is easy to compare this to the user experience on Google Docs. However this is one very important difference.

In Google Docs, you are all editing the document on the server. No one has to hit save - the changes are 'live'.

In Node-RED, nothing is saved in the runtime until someone presses the Deploy button.

That difference is very important as it raises a number of questions over what happens when a user hits Deploy.

They will end up deploying their work and whatever the other user was in the middle of doing - with no guarantee the other user was ready to deploy their work. They could completely break things. This is one of the reasons I haven't tackled this yet - despite a few early experiments. And it is why the current concurrent editing model is based around when a user Deploys their work.

As I wrote above, within a small team, I think it's appropriate to deal with this by an arrangement between members.
Our users have similar issues with team development on current Node-RED and they are covering the issue by operations.
However, there may be some support features that need to be improved, such as a feature for helping participating users agree on deploy.

My worry is the feature makes the collaboration issues harder - because there is nothing built-in to help co-ordinate deploys. User's could get into a real mess if this feature allows User A to deploy User B's half-finished work. Even if it relies on co-ordination outside of Node-RED, accidents still happen.

I understand such concerns. I think that one guard is that this feature is opt-in feature. So, we can expect team members understand the behavior using it.
As for the support function for this, for example, notification to the user who is editing and authorization from them may be useful.

I think the design needs to carefully describe what the user workflows are so we can see what type of interaction is possible and what issues come up.