Looking great! I really like it!

[Mohamed Mansour]

I am discussing this on Google+

https://plus.google.com/116805285176805120365/posts/8SJ7qbZ74p1

I am wondering, since it is now an open project, do you guys have a roadmap on what the future for Collide would be? 

Is it possible to move this to GitHub as well, GitHub has a better community based collaboration tools that make contributing code a lot easier and saner.

[Scott Blum]

Good questions.  I think we'll stay on Google Code for the time being.

As far as near term roadmap, here are my rough thoughts:

There are a number of client-side things still to enable, such as collaborator cursor/highlight, collaborator tracking, the debugging extension, etc.  Jaime has more details on this stuff, so I'm not going to elaborate those.

Server side:

1) Fixes for bugs and race conditions in the file system code.  For example, if you try move a directory on a Windows box, you get an AccessDeniedException.  I won't be able to debug this myself since I'm losing access to Windows soon.

2) FileEditSession needs to smartly merge on-disk changes into active edit sessions.  You should be able to use sed or some external tool to edit a file on disk, and have the changes merge and propagate.  I can give more details on this task.

3) GC inactive (ie, saved) FileEditSessions.  Probably some heuristic sorting like (file size * time since last edit) would allow us to keep the top N in memory and dump the rest.  N could be determined by a target memory usage too.

4) Larger scope, we need to rethink how the server accesses the file system in general.  Probably, the best model is for a single thread (or at least, a single thread at a time) to be able to hit the FS.  The FileTree verticle tries to do this internally, but it's currently possible for the FileTree verticle and EditSessions verticle to race.

[Freeland Abbott]

Scott, I've recently gotten myself a Windows setup, if you want to send me an issue for that one when I get back.

Generally, we've salvaged a useful slice out of a larger project that, sadly, wasn't open-sourceable because it was tied to other Google internals.  I think our first order of business is to recover some of the smoothness we lost in that salvage job.

I would like to see us expand our server-side support (obviously, that side lost a lot in the salvage, since we couldn't exactly separate the Google server code from "Google internals")... in particular, the out-of-the-box application EVERYONE saw for our original setup was an academic problem-set environment: professor sets up some framework, students branch their work from it and complete the problems, professor and TAs review their code.  I'd like to re-enable that story.

On Monday, July 9, 2012 10:51:41 AM UTC-4, Scott Blum wrote:

Good questions.  I think we'll stay on Google Code for the time being.

As far as near term roadmap, here are my rough thoughts:

There are a number of client-side things still to enable, such as collaborator cursor/highlight, collaborator tracking, the debugging extension, etc.  Jaime has more details on this stuff, so I'm not going to elaborate those.

Server side:

1) Fixes for bugs and race conditions in the file system code.  For example, if you try move a directory on a Windows box, you get an AccessDeniedException.  I won't be able to debug this myself since I'm losing access to Windows soon.

2) FileEditSession needs to smartly merge on-disk changes into active edit sessions.  You should be able to use sed or some external tool to edit a file on disk, and have the changes merge and propagate.  I can give more details on this task.

3) GC inactive (ie, saved) FileEditSessions.  Probably some heuristic sorting like (file size * time since last edit) would allow us to keep the top N in memory and dump the rest.  N could be determined by a target memory usage too.

4) Larger scope, we need to rethink how the server accesses the file system in general.  Probably, the best model is for a single thread (or at least, a single thread at a time) to be able to hit the FS.  The FileTree verticle tries to do this internally, but it's currently possible for the FileTree verticle and EditSessions verticle to race.

[Joshua Ma]

Yes! As a college student, I've actually considered building that exact use case.

It would be great to have a web API to link to collide-editor sessions. The use case I'm thinking of would involve a stackoverflow-like discussion board where questions are asked, (live) snippets are included, and any deeper discussion can dive into the source code via collide.

[Freeland Abbott]

Well, to be clear, I'm not specifically interested in the discussion board element (nor would I necessarily choose stackoverflow as a model there), and my use case isn't so much "deeper discussion [diving] into the source code via collide"... my model is much more the case of a team assignment, where each team starts from some (possibly empty) baseline and goes off to do its own work from there, turning in the final results for evaluation.  If you had a "nice" TA, he or she might be available to dive to help you out, or the professor might discuss selected highlights with the larger class in some sort of after-action presentation, but you'd be more likely to do the diving with your own teammates (i.e. pair-programming).

The features required to offer that sort of thing, I think, are a somewhat more "real" authentication and authorization module (i.e. other teams can't peek at your team's work, but the TAs and professor can), and a "workspace" concept (for each team's space) and the ability to create it by copying an existing one (namely, the TA-owned baseline).

[Joshua Ma]

Yeah, I'm not hoping for a mini stackoveflow out of this project, just the APIs to make that possible one day.

More generally, will there be a roadmap of sorts?