[racket] Google Summer of Code 2012 Ideas

On Thu, Mar 01, 2012 at 11:02:27PM -0500, Stephen Bloch wrote:
> 
> On Mar 1, 2012, at 2:21 PM, Asumu Takikawa wrote:
> 
> > We are currently putting together an application as a mentoring
> > organization for the Google Summer of Code 2012, which is a summer
> > program in which Google pays students to work on open source/free
> > software projects.
> > 
> > As part of the application, we are currently collecting project ideas
> > for our "ideas page" that gives applying students ideas for projects
> > that can be completed in 12 weeks. If you have any ideas along these
> > lines, please contribute to our wiki page:
> > 
> > https://github.com/plt/racket/wiki/SoC-Ideas-2012
> 
> I don't actually have a github account, but I wanted to mention the following idea both to current Racket developers and to potential student programmers.  Could somebody add it to the wiki for me?
> 
> Summary: a DrRacket plug-in to enable real-time collaborative editing of a source file, possibly with fine-grained logging as well.  Two or more different programmers each edit the same file simultaneously, and edits one of them make show up immediately on the others' screens.
> 
> Benefits: The benefits of collaborative editing should be obvious, the benefits of the logging feature less so.  I attended a SIGCSE talk this morning on a program called CodeWave which provided both collaboration and (keystroke-level) logging, which the student programmers and/or their instructor can play back to see what process they were following, what kinds of mistakes they make most often and how they dealt with those mistakes, etc.
> 
> Requirements/Difficulty: Will need to hook into DrRacket.  Will need some kind of server, with user authentication and permissions (so a specified set of students have access to the shared file); see the project already on the Wiki about adding git support to DrRacket.
> 
> Possible mentor: I don't know.  Guillaume Marceau has done some of this, but I'm hesitant to volunteer him without asking :-)
> 
> Other:  I'm not wedded to the "log every keystroke" idea: for simultaneous editing, you want to synchronize no less often than every few keystrokes, but you might not want a separate log entry quite as often.  Which sort of inverts the git ideal: it encourages you to commit locally fairly frequently, but push to the server only every several commits.  I'm thinking of something that effectively pushes every few seconds, but only every several pushes become a distinct "commit" record.
> 
> A less elaborate version wouldn't log much of anything, but would still synchronize with a server every few keystrokes.

Two parts to this -- the editor, and a message/event/state maintenance system.

YOu don't actually *need* a server as long as clients can communicate.

Timestamp the messages in an unambiguous fashion, possibly 
something like a pair (local time. client identity).  Arrange to have 
all messages processed sorted by such a time-stamp.   Write the 
editor in a functinoal style -- you know, as a mapping that 
takes a state and a sequence of messages and returns a new state.  
When a message arrives out of order, possibly delayed, you can replay 
the sequence of edit commands from an earlier state.  Both client 
machines can do this imdependently.  THe purpose of the unambiguous 
time-stamps is to ensure that they will eventually converge on the same 
sequence of edit operations.

If you replace the editor with something else, you could have a 
multiplayer game.

Conclusion: the message/event/state maintnance system is probably a 
useful tool in its own right, and should be implemented as a 
general-purpose tool.

-- hendrik