SQuire, an Online Collaborative IDE

The proposer's initial set of specifications were as follows:

• Real-time creation of shareable, private "rooms".
• Color-coded text to see who coded what
• built-in compiler/interpreter to show input/output. Freezes editing while code is being compiled/interpreted.
• Built-in, in-line compile-time/interpret-time debugging
• Multiple "pages" - allows for organization of code and "includes"
• Ability to import/export code/plaintext
• Rooms deleted after set period of time (12/24 hours?) of no connections.

• This thing will be a Wiki, and a MUD, and a roguelike, for collaborative coding.
• The only language that SQuire is required to support is Java. If you design it to be multi-language, so be it.
• If you want to use anything but Java + libGDX, you can propose it and explain why. Be prepared for a management veto. Implementation language is not usually part of software requirements; its selection is best made based on requirements. But sometimes management mandates it.
• The original proposal did not include a plan about how/where code would run, whose resources would be consumed, and how to address the obvious security nightmare.
• Where code must run: an owner/client box. Each "world" will only run on its owner's machine, and only when they are logged in.
• State, though, may be saved in a SQL database. Specifically, if this were on source forge, it would provide MySQL or whatever. Your team will eventually have to decide how/where state is saved. One option is: the owner's hard drive.
• How to address the security nightmare:
  • support only a tiny subset of real Java
  • support enough Java to run interesting toy programs
  • all computing consumes a scarce and valuable resource ("energy"); code stops if it runs out
  • energy accrued slowly by: keystrokes, mouseclicks; bonuses for task completion, such as sending a text chat message, digging out a cell on the map, or modifying code and compiling successfully.
• Rooms will have editable textual descriptions, not just code
• A user will see the textual description, and others present, when entering a room.
• In order to help users to navigate/orient themselves, rooms will be organized within 2D "levels", sets of which will constitute "worlds".
• "Rooms", if you add code to them, will correspond in a 1:1 manner to "functions"
• "Rooms" may have passages to other rooms. I have been trying all my life to learn how to spell corridor, but it is too hard.
• "Rooms" and corridors, will be "dug" out of a blank map, by an industrious user.
• User accounts, tied to e-mail addresses, with an e-mail validation mechanism. User profile includes e-mail, a profile image, list of friends and owned worlds.

• If we want to color code by user, does that mean we don't do syntax coloring? Or that user color code is in a sidebar? Or that the syntax coloring is foreground color, and the author color is background color?
• Should user color be assigned arbitrarily or part of user profile/preferences? Temporary or persistent?
• Do we really want this thing to be browser-based? What are the pros, cons, and implications/consequences?