Resources - abstractfactory/pipi GitHub Wiki

Resources

Resources represent content of any type.

Examples include character, rig, shot, level, user, configuration etc. A prime distinction between resources in Pipi and that of other content management systems lies in how content and meta-content live together on the file-system.

Traditionally

Databases are a favoured method of persisting and accessing metadata - whereas files are stored on disk - possibly due to its performance benefits. What is usually overlooked however is the added maintenance and learning curve. Tools and processes accommodate for their differences depending on the task at hand. For instance, publishing an asset typically involves storing files on disk along with recording relevant data with a database. The end result is a smart database and dumb resources.

How things can be different

It is possible to allow resources to fend for themselves; to describe itself and to communicate with the tools that operate on it. This means no synchronisation and an added flexibility in how you transfer, archive and otherwise process your resources and metadata, such as specifying rules on a per-resource level like junctions across directories or merging of multiple hierarchies into one; for either cosmetic and performance concerns.

Typelessness

All resources are created equal. An overarching design decision of Pipi was to facilitate both for the large and small productions; to those with a single shot and to those with hundreds. Rather than force resources into pre-defined categories, resources are tagged with relevant metadata used in identifying what they do and how they are used. It is then up to the recipient tool to use the data it has been developed to handle.

This allows the smallest of studios to define simple hierarchies and work upon it with the same feature film-strength tools - without the additional overhead of the otherwise large hierarchies and added metadata - resulting in faster work while small and maintained workflow as you grow to take on larger projects.

Traditionally, data is segregated prior to initiating a new project. assets are assets, sequences are sequences and tools are developed to facilitate them both. Then, when categories appear within each category - rigs, shaders, shots, configuration - tools are updated to facilitate their new behaviour and responsibility.

Conversely, tools in Pipi aren't built per type but rather types define what you as a user can get out of the resources - a data-oriented paradigm. The difference lies primarily in the long-term maintenance of a production pipeline as you'll find resources responding to change in ways not previously possible.

Schemaless directory structures

Identify assets without pre-defined schema. What this means is basically that you may start out with any structure and change things around without breaking your tools nor pipeline.

See also

Decentralised metadata.

For resources to remain equal, metadata had to take the stage. Metadata is stored together with content, without relying on a database. Databases are used solely for performance and may thus be removed, replaced or upgraded without affecting what matters; the data.

See also

Automatic generation of structure, pre-set/template (planned)