Foundation data structures

• 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 company LDAP and maybe sendmail services
  • Ultimately, each organization can create groups, which allow for access privileges within the organization
• Any given site (or organization or group or user within a site) supports multiple workspace servers, which are web servers which can manage user workspaces
  • There is a default workspace manager hosted on the Maqetta server
  • Non-default workspace servers are identified by simple URLs, which point to a remote server that implements the appropriate Orion file client protocols
  • 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!)
• Each project can have multiple libraries' (JavaScript libraries)
  • Libraries are either copied in or symbolically linked into projects within a particular folder (./lib by default)
  • The list of libraries available to copy or link into a new project by default is specified by a library configuration file (under the hood, a text file, probably JSON) that can be defined by site admin, organization admin, group admin or user
• For each user workspace, there are multiple possible library servers'. Library servers provide JavaScript libraries (e.g., dojo, jQuery) to user workspaces.
  • For a particular user project, there is an implicit library server within a particular folder in their workspace (i.e., './lib'). See below for how Maqetta determines which libraries are in ./lib.
  • The initial contents of ./lib (e.g., include dojo? include jQuery?) for each newly created project are determined by a combination of user config settings, group config settings, organization config settings and site config settings.
  • There is always a default library server on the Maqetta server
  • Down the road, we might support non-default library servers are identified by simple URLs, which point to a remote server that implements the appropriate library server protocols, where library servers can be added by a site admin, organization admin, group admin or user.
  • But sites, groups and individual users should have able to update configuration settings to add additional URLs
• 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.