Foundation data structures

Table of Contents About this page Sites, organizations, groups and users Workspaces, workspace servers and projects Libraries and library servers Custom widgets and custom libraries To be addressed later

About this page

This page describes the foundation data structures for the Maqetta cloud application that supports multiple users.

Sites, organizations, groups and users

• There are multiple sites, where a 'site' is a server that hosts Maqetta
• Within a given site, there are multiple users, groups and organizations.
  • We already support multiple users (although lots of enhancements needed there)
  • An organization typically would be a company, such as IBM or American Airlines, with the idea that ultimately Maqetta sites would offer secure multi-tenancy and provide server-side bridges to organizational-specific LDAP and maybe sendmail services. Each organization has one or more organization admins;
  • (Down the road) an organization admin can create groups, with one or more group admins. The main purposes of group.
    • Shared configuration settings (e.g., which widgets and themes should be used by a particular collection of users)
    • Access privileges (e.g., only people within group A can view each other's workspaces)

Workspaces, workspace servers and projects

• A workspace server is a web server that can manage Maqetta workspaces.
  • Workspace servers are identified by a simple URL, which points to a server that implements the appropriate Orion file client protocols
    • A workspace server can be the same server that hosts the Maqetta application or can be a remote server
  • There is a built-in simple workspace manager that does simple saves into a Unix file system on the same web server that hosts the Maqetta application (i.e., what we have today)
  • We are likely to offer other built-in workspace managers that support source control systems such as Git and RTC. (We will partner with the Orion project on these built-in workspace managers)
  • The list of workspace servers can be modified by site admins, organization admins, group admins, or individual users.
• Users can have multiple workspaces
  • Each new user gets a single default workspace for each workspace server attached to his account
  • Down the road, users will probably want us to support the ability for a given user to have multiple workspaces on a particular workspace server, but this is low priority for short-term given that we already support multiple projects. Nevertheless, we should architect our code to allow for this possibility down the road
• Each workspace can have multiple projects (already supported today!)

Libraries and library servers

• A library server is a web server that implements Maqetta's library server protocols and delivers a library package (including associated metadata) that can be "installed" into a user project. (Installation is either copy or a magic symbolic link.)
• A library might contain the following things:
  • Runtime JavaScript (and associated CSS, HTML snippets and images)
    • The runtime JavaScript often will include widgets and themes
  • Widget and theme metadata (see sections on widgets below)
• Maqetta will support a library configuration file (probably a simple JSON file)
  • Lists the libraries that should be made available to user projects
  • List which libraries should be included by default whenever a new user project is created
  • Can defined by site admin, organization admin, group admin or user
  • For each library, the config file lists:
    • URL of library server
    • Library name and version (e.g., dojo 1.7)

Custom widgets and custom libraries

• When a Maqetta user does a "Save As Widget" operation, maqetta creates a single-widget library.
• We will provide documentation that tells users how to manually consolidate custom widgets into a single library (versus one library for each widget)

To be addressed later

• Within each library folder, we should look for JavaScript library metadata (a simple JSON file, perhaps foo_lib.json) which identifies each different JavaScript library
  • Library metadata files point to any helper files (usually, JavaScript files). The main theme editor HTML file probably should be listed here, but supplemental HTML for widget collections loaded by dijit.layout.ContentPane (href property) should be associated with the corresponding widget collection.
• Within each JavaScript library, we need to search for:
  • "Widget collection metadata" files (what we now call widgets.json).
  • Right now for Dojo we have one massive widgets.json file. This isn't scalable and manageable for the long haul because Dojo's widgets are decentralized, with various widgets in dojox. and various future widgets in the Dojo package repository. In particular, we should tree Dijit and dojox.mobile as separate widget collections.
  • Each widget collection indicates what devices it supports ("all", "desktop", "mobile", or specific platforms such as "iPhone")
• Within each "widget collection", we should look for:
  • Theme files (what we currently name *.theme). This also needs to be decentralized for the same reasons as previous bullet. The *.theme files need to identify:
    • Which JS library and version
    • Which widget collection
    • Which device ("all", "desktop", "mobile", or specific platforms such as "iPhone")
  • Theme set files. (It might turn out that we only need a single one of these throughout Maqetta's history, for dojox.mobile, but maybe some custom widget libraries will have device-specific themes)
• The *.theme files need to identify:
  • Which JS library and version
  • Which widget collection
  • Which device ("all", "desktop", "mobile", or specific platforms such as "iPhone")
  • Whether or not it is a "wireframe" theme (i.e., handdrawn look&feel)
• In terms of how this relates to custom widgets, I'm thinking that the "save as widget" action creates a widget collection (i.e., a new folder in ./lib) that happens to contain only a single widget.