Re: 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
> 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
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
Conclusion: the message/event/state maintnance system is probably a
useful tool in its own right, and should be implemented as a
Racket Users list: