This document dives into explaining the higher-level architecture as well as some of the decisions involved in finding it.
Copyright and Language can be found in RFC1
This document is governed by the Consensus-Oriented Specification System (COSS).
To make the Pipi code base as easily digestable and extendable as possible for an agile development-style. This is in contrast to the previous architecture in which all code reside within a single root directory and extensions scattered within.
To facilitate the requirements specified in RFC25, Pipi is divided into 4 modules*
Foundation defines objects that operate across all other modules and represents the lowest-level implementations of re-usable components.
Domain defines objects that only operate within a single domain, or industry -
web to name a few. Each Domain features objects only relevant to the specific Domain -
film may for instance define
sequence objects, whereas
games have their own
Bindings are application-specific implentations also known as Integrations. E.g.
pimaya is a Domain-module featuring objects only relevant to Autodesk Maya; such as
offline file objects.
Finally, the Custom Development module represents the work put on top of Pipi at each facility using it and could potentially contain the glue code that connects the overall operation of the studio with Pipi.
* Module in this context is defined as
Each of a set of standardized parts or independent units that can be used to construct a more complex structure. - Google Definition
This modularisation facilitates two main purposes;
Pipi evolves around a Service-Oriented Architecture, which is defined as:
Service-oriented architecture (SOA) is an architectural style for building systems based on interactions of loosely coupled, coarse-grained, and autonomous components called services. Each service exposes processes and behavior through contracts, which are composed of messages at discoverable addresses called endpoints. A service’s behavior is governed by policies that are external to the service itself. The contracts and messages are used by external components called service consumers. - SOA Patterns, Arnon Rotem-Gal-Oz, 1.2
Which makes each components distributable, decentralised pieces of intelligence.
To facilitate for SOA, Pipi employs the concept of a
service which is defined as
a facility supplying some public demand - Merriam-Webster’s dictionary
Which is further defined as
A service should provide a distinct business function, and it should be a coarse-grained piece of logic. Additionally, a service should implement all of the functionality promised by the contracts it exposes. One of the characteristics of services is service autonomy, which means the service should be mainly self-sufficient. - SOA Patterns, Arnon Rotem-Gal-Oz, 1.2.1