Location Details

Constructivity Model Server

Read	Try	Buy
		Licenses may be purchased for $799 USD. VISA and MasterCard accepted 9AM-5PM Central US Time at +1.888.505.0996, or email info@constructivity.com for other arrangements.

Constructivity Server keeps track of project changes from people inside and outside your team, recording and managing every impact.

But revision control is just the beginning. Real-time collaboration, document synchronization, constraints, approvals, conflict resolution, clash detection, and building automation integration are just some of the added features.

Libraries

Projects can have any number of versions and branches which can be referenced by other projects. Any version can be viewed, compared, or merged with another version.

Classifications

Projects can be organized into a hierarchical classification structure to make it easy to find related data.

Documents

Projects can have documents attached containing arbitrary data or synchronized information. For example, Microsoft Project schedules can be associated with a project such that changes made to the building information model are synchronized with external files and vice-versa.

Interactivity

In addition to solo work sessions, multiple people can work on a project at the same time where changes are instantly synchronized.

Security

All projects and objects can be secured such that the right people have access to read and/or write. Any object can be temporarily locked such that only a particular person can make changes over a time period.

Constraints

Any object or property can have constraints associated requiring values to meet specified targets. Constructivity Server can enforce such constraints, preventing anyone from submitting changes that violate rules, or else flag such changes so they are well known.

If people make conflicting changes, they can be required to merge their changes by either keeping their changes, replacing with others, or leaving the decision for later if permitted to do so. This means there is both the rigidity needed to keep the project on target yet flexibility to merge last-minute changes and resolve conflicts later at any time.

Approvals

Any object or property can have approvals associated requiring permission for changes to be made.

If people make changes to restricted objects, then such changes are routed to interested parties for acceptance.

Approvals can be optimistic (accept changes pending later approval) or pessimistic (record changes to be applied later upon approval).

Automation

Building control systems can be attached to the server so energy usage, security, lighting, HVAC, and audio/video systems can be monitored and controlled.

Scalability

Constructivity Server is designed for fast data retrieval and posting. Data manipulation speed is independent of the size of a project, supporting millions of building elements with thousands of changes. Rather than taxing a database to render BIM content on demand, all content is pre-generated for instant retrieval.

Manageability

Constructivity Server does not rely on any external database or web server; it stores all data within a folder structure as native IFC files and index files. Getting a server up and running requires two settings: folder location and web server port.

Extensibility

While Constructivity Editor seamlessly integrates with Constructivity Server and can edit 100% of data, custom applications can also access the server. Constructivity Server uses an extremely simple API such that custom applications can integrate with ease. There are three methods (GET/POST/DELETE) which simply accept IFC files containing all the information for change control, revision history, and merging.

Configuration

The model server runs on Windows XP, Vista, 7, Server 2003, or Server 2008, without any extra software required (no server OS, database, or web server needed). Required hard drive space is proportional to the number of projects, number of project revisions, and the size of each project.

Upon installation, the server is not yet configured to run. It may be started by using either the Constructivity Model Server configuration application or the Windows Services Management Console (accessible from the Windows Start Menu under Control Panel / Administrative Tools / Services.

The Constructivity Model Server configuration tool is accessible from the Windows Start Menu under the Constructivity program folder, and requires administrative permissions on the local computer to run.

Server Tab

The Server tab configures the required operating parameters for where data is stored and how it is accessed.

Service

The service status indicates either "Stopped", "Running", or "Unknown". To start the service, click Start. To stop the service, click Stop. Either operation should take several seconds, after which the status will update. An "Unknown" status may occur if the service is uninstalled or is otherwise inaccessible due to permissions. If changing any parameters, the server must be stopped and restarted to take effect.

Note: Stopping the server will never result in any data loss or corruption, as all operations are transactional.

URI

The default URI settings are to use TCP Port 8080, where the model server is accessible from a web browser on the same computer using the URL "http://localhost:8080".

Note: The default port used by web browsers is 80, which is recommended to simplify the URI (e.g. "http://localhost") and to avoid firewall restrictions. The reason Constructivity defaults to port 8080 is to avoid conflicts with any existing web server during initial setup or evaluation.

Folder

The default folder where data is stored is "C:\CMSERVER". This may be changed to any location on the local computer or a mapped drive.

Data for projects follows a flat directory structure where each project is stored in a separate folder named by a 128-bit unique identifier. For backup purposes, this folder (or individual project folders within) may be simply copied. For staging or archival purposes, this folder may be copied to a folder of any web server, and content is accessible the same way but as read-only.

Note: The reason folders use identifiers rather than project names is to provide a unique name that is guaranteed not to change, avoiding issues as projects are renamed or moved. The identifiers are based on the corresponding IFC project identifier (IfcProject.GlobalId).

To support server redundancy and/or scale out, multiple model servers may share the same folder, where file access is synchronized. Each server is designed to support thousands of users, so scaling out does not need to be considered in most scenarios.

Security Tab

The Security tab configures general security settings for the server overall.

Server Operation Mode

The operation level provides a general firewall for whether the server operates as read-only, read-write, or allowing deletions. For maintenance operations such as backing up, the server may be set to GET to disallow any modifications. The server will return "HTTP/405 Method Not Allowed" if PUT or DELETE is used when disallowed.

Access Control Level

The access control level indicates the granularity of account permissions. There are four levels, each providing additional capabilities at the expense of additional administration:

No Access Control: Anonymous users may perform any operation.
Server Access Control: Login with username and password is required, where each user has server-wide permissions.
Project Access Control: Users may be assigned permissions to specific projects within the server.
Object Access Control: Users may be assigned permissions to specific objects within projects.

Constructivity Model Server has multiple editions based on available access levels and number of users. Consult www.constructivity.com for licensing information.

Administration

Administration of projects, branches, versions, accounts, and permissions may be done through Constructivity Model Viewer connected to a server.

In Constructivity Model Viewer, go to the File menu, select the Open tab, and click the Open Server File button. This will display the Open Server File dialog box.

Server Dialog

This dialog box allows selection of a server and opening a project file, optionally specifying a branch and version. It also provides access to server accounts and project permissions, as well as deleting a project.

The Server box on the top allows specification of the server URL. When first installed, it defaults to "http://localhost:8080", the address of Constructivity Model Server on the local machine.

The Project list displays details of each project within the specified server.

The Branch box in the lower left allows specification of a branch within the selected project, launching the Branch Dialog.

The Version box in the lower right allows specification of a version within the selected branch, launching the Version Dialog.

Note: Creating projects is not done through this dialog but by using File / New, followed by File / Share / Submit.

Branch Dialog

This dialog box allows selection of a branch within a project. It also provides access to creating branches, renaming branches, editing branch permissions, or deleting a branch.

Version Dialog

This dialog box allows selection of a version within a branch. It also provides access to rolling back versions.

Accounts Dialog

This dialog box allows adding, removing, and editing of accounts on the server. If the server is configured for Server-Level or Project-Level security, then only users listed within this dialog may login to the server.

There are three levels of server access for users:

Login: User may login to the server and navigate projects where permission is granted. This is the recommended level for most users.
Create: User may create new projects on the server. This is recommended for managers commissioning new projects.
Admin: User has full access to the server, including deleting projects, editing accounts, and assigning server-level permissions. As a security precaution, this is recommended for senior management and IT administration.

Permissions Dialog

This dialog box allows assigning accounts to projects and specifying project permission level. It also allows assignment of account permissions to branches. If the server is configured for Project-Level security, then only users listed within this dialog may access the specified project or branch.

There are three levels of project/branch access for users:

Read: User may download versions contained within the project or branch.
Write: User may submit versions within the project or branch.
Manage: User has full access to the project or branch, including deleting branches, rolling back versions, and assigning permissions within the project/branch.

Web Interface

The web interface allows browsing projects, branches, and versions. It is intentionally minimal, as most editing operations of a building model require a rich 3D client to be useful. This design approach also allows all content of the model server to be copied to a regular web server for read-only access. Pages on the web interface link to IFC files which may launch the default IFC viewing or editing application such as Constructivity Model Viewer or Constructivity Model Editor.

Server Index

The server index page displays all projects on the server and includes links to download the current version of a project or to browse branches and versions of the project.

Project Index

Each project index page displays all versions within the branch and includes links to download each version. It also includes a list of child branches with links to the index page of each branch.

IFC Interface

Here is where you will find all technical information regarding how to access Constructivity Model Server from custom applications.

Design Background

Projects are stored internally as a flat list of folders named by GUID, though may be presented as a hierarchy based on classification and project display names. Changes are captured on a per-object basis, indicating a create, update, or delete operation, for which a batch of operations are submitted as a revision. All changes submitted on a project are recorded and maintained forever (until otherwise deleted).

The server stores any type of document (not just IFC), and represents all files using a GUID for identification and a 32-bit integer for each revision. IFC files have additional implications where partial updates are supported, validation may be performed by the server, and summary files are automatically updated to reflect changes.

The server maintains a flat list of projects and arbitrary documents addressed by a 128-bit unique identifier (GUID). Each project has one or more versions identified by a 32-bit integer. Each version may have one or more formats available by requested MIME type. Each project may have child branches, which are treated as any other project but contain a link back to the parent project.

The server maintains a special "Archive" project which maintains a list of all projects and server-scoped accounts and permissions. Each project and branch has an index file which maintains a list of versions and direct child branches.

Validation

Submission of IFC files to the server includes the following checks:

Validation	Description
Syntax	The submission must have valid syntax according to the IFC schema and rules.
Permissions	The submission must not change any objects for which the user does not have write permission.
Locks	The submission must not change any locked objects unless the user is the owner of the lock.
Conflicts	The submission must not update or delete any objects that have been changed by others since synchronizing.
Constraints	The submission must not have any values that violate an IfcMetric with ConstraintGrade=HARD.
Approvals	The submission must not have any values that violate an IfcApproval with ApprovalStatus=NOTAPPROVED.

Trusted clients may also perform such checks on a local PC, reducing the load on the server. If a submission is rejected, constraints are generated for offending items which may be addressed by the client application.

URL Format

The format of URLs is as follows: "{Protocol}://{Server}/{Project}/{Version}", for example, "http://localhost/0123456789ABCDEF0123456789ABCDEF/00000003.ifc". The URL format should not be depended upon; URLs should only be used as retrieved from the server root (starting from the root) and not constructed by a client application.

Components are defined as follows:

Protocol: Identifies the Internet protocol to use which may be either "http" or "https".
Server: Domain name of the server such as "www.constructivity.com".
Project: 128-bit hexadecimal globally unique identifier (GUID) of an archive, project, or branch.
Version: 32-bit hexadecimal sequential index (starting at 1) unique within its project.

The server maintains a classification hierarchy which maps user-friendly URLs to the GUID-based permanent addresses. For each branch, the server maintains a classification hierarchy which maps user-friendly URL segments to branch indexes.

HTTP Requests

Operations performed on the server follow a REST approach with simple HTTP verbs (GET, POST, and DELETE) without any special parameters or transformations. This also means that the contents within a Constructivity Model Server may be moved or copied to a regular web server and they are retrievable as read-only just like any other web content.

Content is available in the following formats which are returned according to the HTTP "Accept" header:

Format	MIME Type	Description
IFC-SPF	application/step	ISO 10303-21 Step Physical File (SPF) format.
IFC-XML	text/xml	ISO 10303-28 Extended Markup Language (XML) format.
Web	text/html	Web pages are generated for all index and project files.
Image	image/png	Images are generated for all version files defaulting to 256x256 resolution.
Video	video/mpg	Videos are generated animating changes for each version in 1920x1080 resolution.

The server manages various files, each of which support several HTTP methods:

File	URL	Description
Server Root	/	A blank URL redirects to the server's default archive. GET: Redirects to the current Archive Version of the default archive.

Archive Default	/{ServerID}/	This maps to the current archive configuration which maintains a list of all projects, users, and permissions. It is updated by the server upon project creation, deletion, or header changes, or when a client submits a new version for modifying users and permissions. GET: Redirects to the current Archive Version.
Archive Index	/{ServerID}/00000000	Each archive index maintains a list of versions referencing Archive Version files. GET: Retrieves the current generated index. POST: Create a new project within the archive.
Archive Version	/{ServerID}/00000001 /{ServerID}/00000002 ...	Each version file contains all archive data, with version-specific changes indicated on each object. GET: Retrieves the file. HEAD: Retrieves file metadata such as the Archive Index URL using the "Link" header. POST: Submits a new archive version where the URL identifies the baseline version. DELETE: Deletes the archive version (though numbering is kept intact).

Project Default	/{ProjectID}/	This file maps to the current version of a project. GET: Redirects to the current Project Version file.
Project Index	/{ProjectID}/00000000	Each project index maintains a list of versions referencing Project Version files, and a list of child branches referencing other Project Index files. GET: Retrieves the current generated index. POST: Create a new branch of the project. DELETE: Deletes the project.
Project Version	/{ProjectID}/00000001 /{ProjectID}/00000002 ...	Each version file contains all project data, with version-specific changes indicated on each object. GET: Retrieves the file. HEAD: Retrieves file metadata such as the Project Index URL using the "Link" header. POST: Submits a new version where the URL identifies the baseline version. DELETE: Deletes the version (though numbering is kept intact). CONNECT: Connects to a shared session where changes are transmitted in realtime.

Account	/{AccountID}/	This provides access to updating account information in a secured manner. PUT: Submits new account information such as password changes or resets.

The server also supports URL paths based on display names which are constructed as "/{ArchiveName}/{ProjectName}/{BranchNamePath}/{VersionNumber}".

HTTP Responses

The server returns the following HTTP response codes:

Response	Description
200 OK	Indicates successful operation.
201 Created	Indicates project or version was successfully created.
400 Bad Request	The method or posted document has invalid syntax or violates schema rules.
401 Unauthorized	The request requires user authentication.
402 Payment Required	For hosted servers, indicates the account is locked until payment is received.
403 Forbidden	The file was found, but the user does not have permission to modify or delete.
404 Not Found	The file does not exist or the user does not have permission to read it.
405 Method Not Allowed	The server is currently configured to not accept POST and/or DELETE operations.
409 Conflict	The posted revision has one or more conflicts, as indicated in the returned IFC file.
415 Unsupported Media Type	The requested format is not supported.
507 Insufficient Storage	The server has no more storage space or has reached its quota.

HTTP Cookies

The server returns the following HTTP cookies:

Cookie	Description
Session	GUID that identifies the session to support future requests without authentication.
Account	GUID that identifies the active user account to support account updating.

Retrieving Archive Index

Every server has a special project that provides a directory to other projects on the server, along with user accounts and permissions. This special project is accessed the same way as any other project, and a new version is generated whenever a project, account, or permission is created or deleted.

The contents of a server may be accessed by retrieving the Archive Index having the URL "GET /". The HTTP AcceptType must be set to the format "application/step" for IFC-SPF or "text/xml" for IFC-XML; otherwise HTML is returned.

The IFC file returned consists of a single IfcProject describing the server itself, with server configuration versions represented by IfcLibraryInformation and related to the IfcProject by the IfcRelAssociatesLibrary relationship. IfcLibraryInformation has attributes describing the Location (URL), VersionNumber, VersionDate, PublishingUser, and Description.

The Archive Index only provides a list of configuration versions; the actual data is stored in the versioned project itself. To get this information, the URL of the IfcLibraryInformation with highest VersionNumber should be used.

Retrieving Archive Version

The latest version of the Archive may be accessed using the URL of the latest version contained within the Server Index. Such URL may look like "GET /00000000000000000000000000000000/00000001.ifc", where the version number increments with each server configuration change.

The following HTTP headers are returned:

Allow: indicates valid actions according to the current user, which may be GET, POST, and/or DELETE.
ETag: indicates the archive version identifier.
Last-Modified: indicates the archive version date.
Link: indicates relative URLs according to the following relations (see RFC 5988):
- "predecessor-version": the previous Archive Version, if any.
- "successor-version": the next Archive Version, if any.
- "version-history": the Archive Index.

The IFC file returned consists of a single IfcProject describing the server itself, with referenced projects represented by IfcProjectLibrary and related to the IfcProject by the IfcRelDeclares relationship. Each IfcProjectLibrary has attributes describing the Name, Description, ObjectType, Phase, and LongName. Each IfcProjectLibrary indicates the URL and current version using IfcLibraryInformation related by the IfcRelAssociatesLibrary relationship. IfcLibraryInformation.Location indicates the relative location on the server such as "/0123456789ABCDEF0123456789ABCDEF/00000000.ifc".

Branches are represented by nesting where each IfcProjectLibrary relates any branches (also using IfcProjectLibrary) using the IfcRelDeclares relationship, recursively. Permissions may be assigned to branches the same way as projects, where permissions are inherited as additive.

Users having access to the server are represented by IfcActor and related to the IfcProject by the IfcRelDeclares relationship. Server-level permissions are represented by IfcActor.TheActor.Roles where IfcActorRole.UserDefinedRole indicates the server permission level as "READ", "WRITE", or "ADMIN".

Permissions to access projects are represented by the IfcRelAssignsToActor relationship where RelatingActor points to the IfcActor and RelatedObjects includes one or more IfcProjectLibrary objects. Project permissions are encoded in IfcRelAssignsToActor.ActingRole where IfcActorRole.UserDefinedRole indicates the project permission level as "READ", "WRITE", or "ADMIN".

The IfcProject may organize projects into a hierarchy using IfcClassification related by the IfcRelAssociatesClassification relationship. Each IfcProjectLibrary may be listed in such hierarchy using IfcClassificationReference related by the IfcRelAssociatesClassification relationship. IfcClassificationReference.Name is the display name to be presented.

Creating Projects

A new project is uploaded to the server by uploading an IFC file to the Archive Index URL using the HTTP POST method.

The server will store the new project using the GlobalId of the IfcProject, generate a Project Index, generate the first Project Version, and generate a new Archive Version to include the project using the Name, Description, ObjectType, Phase, and LongName attributes. The server will return HTTP/201 if successful, and the client should follow the behavior as described for Submitting Project Versions.

Retrieving Project Index

The available versions and branches for a project may be accessed by retrieving the Project Index URL (which is provided by an Archive Version).

The following HTTP headers are returned:

Allow: indicates valid actions according to the current user, which may be GET, POST, and/or DELETE.
Link: indicates relative URLs according to the following relations (see RFC 5988):
- "latest-version": the latest Project Version within the current branch, if any.
- "working-copy-of": the Project Index of the parent branch, if any.

The IFC file returned consists of a single IfcProject describing the project itself, with versions represented by IfcLibraryInformation and related to the IfcProject by the IfcRelAssociatesLibrary relationship. IfcLibraryInformation has attributes describing the Location (URL), VersionNumber, VersionDate, PublishingUser, and Description.

Any direct branches within the project are represented by IfcProjectLibrary related to the IfcProject by the IfcRelDeclares relationship. Each branch has its URL indicated by the Location attribute on IfcLibraryInformation which is related to the IfcProjectLibrary by the IfcRelDeclares relationship.

Each branch is it's own project and works the same as any other project, where listing versions and direct child branches which may be retrieved recursively.

Retrieving Project Versions

A version may be retrieved by using a URL provided by a Project Index for a particular version such as "GET /0123456789ABCDEF0123456789ABCDEF/00000003".

The server will return HTTP/200 (if successful) with the following HTTP headers:

Allow: indicates valid actions according to the current user, which may be GET, POST, CONNECT, and/or DELETE.
Content-Disposition: indicates a filename to use for saving, which may be stored in any referencing IfcLibraryInformation.Name.
ETag: indicates the version identifier, which may be stored in any referencing IfcLibraryInformation.Version.
Last-Modified: indicates the version date, which may be stored in any referencing IfcLibraryInformation.VersionDate.
Link: indicates relative URLs according to the following relations (see RFC 5988):
- "predecessor-version": the previous Project Version, if any.
- "successor-version": the next Project Version, if any.
- "version-history": the Project Index.

The returned Project Version indicates version-specific changes for each object with IfcRoot.OwnerHistory.ChangeAction, indicating ADDED, MODIFIED, DELETED, or NOCHANGE. Client applications may keep such state for visualization of changes, but must clear such state before making additional changes and submitting a new version.

The returned Project Version indicates the baseline version (NOT the current version) through IfcLibraryInformation (as it was submitted) using the following attributes:

Name: The display name of the immediate branch.
Version: The identifier of the baseline version within the branch.
Publisher: The user who submitted the baseline version for informational purposes.
VersionDate: The date of the baseline version for informational purposes.
Location: The URL of the baseline version in the immediate branch.

If the Project Version was branched, then there is an IfcLibraryReference record for each ancestor branch using the following attributes:

Location: The URL of the baseline version of the specific branch.
Identification: Unique identification of the specific branch.
Name: Display name of the branch.

Submitting Project Versions

A submitted IFC file indicates changes for each object with IfcRoot.OwnerHistory.ChangeAction, indicating ADDED, MODIFIED, DELETED, or NOCHANGE. The FILE_DESCRIPTION header may contain a "Comments" value (using IFC header conventions) reflecting the version comments.

A new version is submitted by performing an HTTP POST to the baseline version URL (indicated at IfcLibraryInformation.Location of the IfcProject). A version may be submitted to a parent branch (referred to as a "forward integration") by using the baseline version URL of the parent branch (indicated at IfcLibraryReference.Location where IfcLibraryReference.Identification identifies the branch).

The server will store the submitted file and update the Project Index to reference the new version submitted using the comments indicated.

The server will return HTTP/201 (if successful) with the following HTTP headers:

Allow: indicates valid actions according to the current user, which may be GET, POST, and/or DELETE.
Content-Location: indicates the URL of the submitted version.
ETag: indicates the version identifier, which may be stored in any referencing IfcLibraryInformation.Version.
Last-Modified: indicates the version date, which may be stored in any referencing IfcLibraryInformation.VersionDate.

After receiving the response, the client application should then update the IfcLibraryInformation record for the current branch using the IfcRelAssociatesLibrary relationship to the IfcProject of the local project. The IfcLibraryInformation should then reflect the Project Version file just submitted using the following attributes:

Location: set to the returned "Content-Location" HTTP header; this may be used later for checking in figure versions to determine the baseline.
Version: set to the returned "ETag" HTTP header.
VersionDate: set to the returned "Last-Modified" HTTP header (reflecting the time on the server).
Description: set to any comments entered about the version submission (as was included in "comments" of the FILE_DESCRIPTION header when submitting).

Receiving Conflicts

If a submission is rejected such as due to change conflicts, then HTTP/409 is returned where the HTTP Body is an IFC file indicating conflicts. For trusted client applications (including Constructivity Model Editor), the server will not attempt to merge changes but will reject any submission where the baseline version (indicated in URL) is not the latest version (another user since submitted), in which case the client application must retrieve subsequent versions to merge and resubmit with a new baseline.

If a submission is rejected, the returned IFC file includes objects having conflicts, where IfcObjective is associated to each object using the IfcRelAssociatesConstraint relationship. IfcObjective contains one or more IfcMetric items describing each conflicting attribute change made by another submission. Each IfcMetric has its ConstraintGrade attribute set to NOTDEFINED, indicating the resolution of the conflict has not yet been established. The IfcRoot-based object itself maintains the state as it was submitted. IfcMetric.Name identifies the attribute and IfcMetric.DataValue represents the conflicting value as IfcText holding an SPF (ISO 10303-21) expression such as "IfcPolyline((IfcCartesianPoint(0.0,0.0), IfcCartesianPoint(1.0,0.0))"

Resolving Conflicts

Resolving conflicts involves either changing attribute values to not conflict, deferring conflicts by setting IfcConstraint.ConstraintGrade on reported items, or suppressing conflicts by deleting generated IfcRelAssociatesConstraint relationships. Once the ConstraintGrade is set to something other than NOTDEFINED, then the conflict is considered acknowledged and deferred. The value used should reflect the perceived severity of the conflict (HARD, SOFT, or ADVISORY). Once all conflicts are resolved, deferred, or cleared, then the file may be resubmitted with constraints intact using POST as before.

Creating Branches

New branches are created by following the same steps for Creating Projects, with the exception that the URL is set to the Project Index of the parent branch.

The server will generate a new Archive Version to include the new branch underneath the specified parent branch or project.

Branch Forward Integration

To merge changes from a parent branch into a child branch, a client application follows the steps for Retrieving Versions for the parent branch and follows the steps for Submitting Versions for the child branch.

Upon merging changes to the local copy, the client application should update the IfcLibraryReference to the parent branch to reflect the new baseline of the parent branch.

Branch Reverse Integration

To merge changes from a child branch into its parent branch, a client application follows the steps for Retrieving Versions for the child branch and follows the steps for Submitting Versions for the parent branch.

The client application may determine the baseline URL of the parent branch by reading IfcLibraryReference for the parent branch.

Deleting Versions

A version can be deleted by using the IfcLibraryInformation.Location URL of the version such as "DELETE /0123456789ABCDEF0123456789ABCDEF/00000007". To preserve referential integrity for clients, version numbers are not re-used. The Project Index will still list any deleted versions but they will be marked as deleted.

Deleting Projects

A project (or branch) can be deleted by using the IfcLibraryInformation.Location URL of the Project Index such as "DELETE /0123456789ABCDEF0123456789ABCDEF/00000000". All project information is permanently deleted, including every branch and version.

Accounts and Permissions

To define users on the server and project permissions, the Archive Project is updated just like any other project such as "POST /00000000000000000000000000000000/00000001" where the version indicates the baseline retrieved. Posting updates to this file requires server administration permission.

Each user is represented by IfcActor and is related to the server-level IfcProject using the IfcRelDeclares relationship. IfcActor.Name holds the username used for login. Passwords are not transmitted in the Server Index file, rather password changing is done through a separate call described below.

Server-level permissions are represented using IfcActor.TheActor.Roles where IfcActorRole.Role is set to USERDEFINED and IfcActorRole.UserDefinedRole uses one of the following values:

READ: Read permission enabling user to login and list projects.
WRITE: Write permission enabling user to create new projects.
ADMIN: Admin permission enabling user to delete projects, manage accounts, and manage permissions.

Project-level permissions are represented using IfcRelAssignsToActor where RelatingActor indicates the IfcActor, RelatedObjects includes each project (represented by IfcProjectLibrary), and ActingRole indicates the permissions using IfcActorRole. IfcActorRole.Role is set to USERDEFINED and IfcActorRole.UserDefinedRole uses one of the following values:

READ: Read permission enabling user to download versions and branches of project.
WRITE: Write permission enabling user to submit versions and create new branches.
ADMIN: Admin permission enabling user to delete versions and branches, and manage project/branch permissions.

There are always two built-in accounts that cannot be deleted or modified (except for the permission level of the guest account):

admin: The built-in administrator account has full access to all operations on the server. This account is always used when logging in as "admin".
guest: The built-in guest account has configurable access to the server, defaulting to none when first installed. The server access permission may be changed to READ to allow anonymous login and downloading of projects. This account is always used when not logging in.

The contents of the downloaded Archive Version may vary according to the logged in account. Administrators will receive all content, while non-administrators will only receive their own account information and project listings for which they have access.

Changing Password

The password of an account may be changed by using the HTTP PUT method with the account URL such as "PUT /0123456789ABCDEF0123456789ABCDEF", with the HTTP Body containing an MD5 hash of username+password. The URL is determined from IfcLibraryReference.Location on the IfcActor representing the user. The IfcActor record for the current user is determined by the GUID received from the server in the "Account" HTTP cookie.

The password may be reset by not passing in an HTTP Body, in which case a new password will be generated and emailed to the user if an email address is defined. Server administrators may call this for any account, while any user may call this for their specific account.

Interactive Sessions

Interactive sessions may be joined by using the HTTP CONNECT method with the Project Version URL such as "CONNECT /0123456789ABCDEF0123456789ABCDEF/00000008". This enables multiple users to instantly see changes they are making, or for monitoring or controlling building automation systems with realtime data changes. To support multiple group sessions, temporary branches may be created with optional permissions assigned.

Once connected, IFC data may be streamed by sending and receiving ISO-10303-21 format. Each client receives changes made by others but not their own changes. Such transmitted data is not recorded anywhere on the server. To record such changes, a version must be submitted.

Choose A Location