mottosso / be

minimal directory and environment management system for collaborative creative projects
GNU Lesser General Public License v2.1
47 stars 4 forks source link

be in running project #15

Open mottosso opened 9 years ago

mottosso commented 9 years ago

goal

To facilitate entering a remotely running project.

See also

Whenever you type

$ be in someproject

be will:

  1. Look for project locally matching someproject
  2. If one is found, enter it
  3. Else look remotely for registered "running projects"
  4. If one is found, download configuration, no data, and enter it
  5. Else fail

    motivation

There's a trend coming to facilitate outsourcing/working with third-party artists but the problem is how to mirror your pipeline across to a workstation outside of your organisation. For someone working remotely, only a very small portion of your pipeline is required, typically (1) a directory in which to save files and (2) a limited set of files related to the work that is to be done. Finally, there needs to be (3) an environment in which project-related pipeline tools can be run.

Be can solve each of these issues.

$ be in indiefilm --enter
Finding running project "indiefilm"..
Username: mottosso
Password:
Pulling studioy/indiefilm-project..
No development directory found. Create? [Y/n]: y
"indiefilm" entered
$

Following this command, the project configuration is downloaded (a few kb's worth of yaml files) and essential data based on some criteria, such as

  1. The username and password entered
  2. The currently logged on user
  3. The user passed to --as someuser
  4. IP address
  5. Geolocation
  6. Any combination of the above

The studio running the project can then register various parts of data to each corresponding criteria.

benefits

With such a workflow, it becomes possible for anonymous artists to join a project and reap the benefits of the existing pipeline while at the same time transparently conforming to the remote workflow. They would enter and operate within a project the same as for any other project, but the associated tools would have access to data relative the currently running project. Enough information to make informed decisions about project-dependent settings, such as where to find files, how to download them, where to save new files and how to share them.

This opens up the door for open source collaborative projects running across the globe with very little overhead. A project could either be designed from scratch to take advantage of distributed development, or retrofitted with the essentials for quick interactions with an outside vendor.

security

Beside username and password, security can walk alongside the traditional SSH securities making data transfers and interactions as safe as possible. The only other issue lies in the actual data transferred, which the responsibility of the author of a running project. In a truly open source and globally collaborative with many anonymous artists , there may still be room for doubt and malicious intent. In these cases, the responsibility and trust is entirely in the hands of the recipient. It is up to them to either trust or distrust a source.

sharing

Once downloaded, an artist will eventually be required to share his work with the swarm. Be opens the door for a common infrastructure on both ends, but doesn't deal in outgoing data. However, thanks to the common infrastructure a link can easily be generated via the context sensitive environment through which to pass data to the correct location. Validation may then be handled, both locally and remotely (e.g. artists checks running locally, and security running remotely) before data is allowed to be sent across.

implementation

As with presets, a running project is registered with a be-running repository. The be.yaml file then contains relevant links either to data directly, or to an intermediary from which to download artist-dependent data in a secure fashion such as any arbitrary SSL protected endpoint..