Splitting off from #1559578: D7 solution for when multiple users are updating an issue simultaneously. What we have now (Conflict module is good enough for the d.o D7 launch, but I think we could do better in the long run, so I wanted to open this so it doesn't get lost.

From my OP there:

One thought would be to use node.js to automagically go out and update the edit forms of anyone else editing a given issue whenever a user successfully submits an update. There'd still have to be some conflict resolution logic on the client so that node.js doesn't just undo your edits out from under you, but somehow alerts you "someone else just updated this, click here to reload the current value" or something.

And from sun in comment #3:

2) Websockets solution, à la node.js, entirely outside and bypassing Drupal for most of the actual concurrent editing time, only stashing new issue revisions (via web service callbacks implemented in Drupal) when the content is supposed to be saved and resolved (no conflicts). (Working on this likely benefits http://drupal.org/project/nodejs and the small(er) crowd of advanced web developers who're capable of setting up node.js & co.)

I just asked in IRC and tizzo and msonnanbaum had an interesting debate about node.js vs redis + ruby to talk websockets. The upshot is "in theory that wouldn't be too hard" but "no, nothing like that already exists"...

I certainly don't want this code to live in project_issue. I think it could be a stand-alone contrib that can attach to any entity edit forms you configure it to. I'm not even sure the infra team would go for this. But, I wanted to open an issue here for now, and we can always move it around to other queues if/when necessary.

Comments

Anonymous’s picture

Anonymous (not verified) commented

this is pretty much exactly the sort of use case the nodejs module was built for.

i'll put my hand up to help with creating a module that requires the nodejs module's functionality to get this working.

redis vs node.js - who cares? my current favourite for this sort of server-side work is Go, but i'm not going to suggest that, because we have the nodejs module built and ready.

dww’s picture

dww
we/he/they
commented

Again, I can't really work on this until after d.o is running D7. And I don't want this to become a distraction from the launch. But... if someone built something like this for a client in the meanwhile, I know d.o would love to be able to deploy it in one of the first post-launch D7 deployments. ;) That is, assuming the rest of the infra team is happy with whatever new services we'd need to be running on our servers to enable this.

I don't personally care about the implementation details, so long as nnewton et al are happy with whatever the requirements are.

dww’s picture

dww
we/he/they
commented

Druplicon just told me that the Changes, yo! sandbox now exists. ;) Thanks beejeebus!