Revision as of 03:05, 2 May 2006

The Parts

• EMU-Protocol
• EMU-Server
• EMU-Client
• ES integration

Developer Requirements

EMU-Protocol

defines Client/Server communication with

• client/server states
• available messages
• client/server actions

Messages

Connection Establishment

Synchronization Check

Data Transfer

Connection Closure

EMU-Server

• stores and manages code-repository
• synchronizes code of clients
• manages Locking-System
• Account-System
• project update
• add/create new code (classes)
• change-logging
• optional: Media-upload
• optional: BackUp-System
• optional: Release-versions
• optional: Server-Admin-Tool

Locking-System

• list of locked code
• check if code (class) is locked
• lock / unlock code (class)

Code-Synchronization

• broadcast code-changes
• bring user code up to date

Account-System

The server uses an account-system to organize its projects and users. Every project has its own users assigned.

Project-Accounts

• project name
• project-admin(s)
• user lists
• project status
• editable / creatable with a project-admin-tool

User-Accounts

• usernames
• used for logins
• assign locked code & changes to users
• online status

Change-Log

The Log helps the users to know what has changed during their last login. It is also used as a look-up table for synchronisation with the clients. Every lock/unlock action is logged with following data:

• user name
• date and time
• type of action
• code element (class name)

Additionally, it provides the possibility for the user to add comments (e.g what he changed, what doesn't work yet...).

EMU-Client

• interface for IDE and server
• provides features to login and communicate with server on an abstract base
• upload/download code elements to/from server
• notify IDE of server-messages (code-updates)
• modular / independent of IDE-integration
• optional: upload media files

IDE-Notifications

The client needs to notify the IDE of the new changes.

ES integration

• minimal change to existing ES-classes and features.
• modular integration: activatable and removable / hideable

User Requirements

• easy to use
• target is a small project group of up to 20 developers.
• code synchronisation process mostly hidden from user
• minimal extra work (less total work)
• better efficiency