-
Notifications
You must be signed in to change notification settings - Fork 1
Design Philosophy
The Islandora Projects beginnings are at the UPEI Robertson library, but it has grown far beyond that. It is now the basis of a large commercial venture and used by other libraries, unaffiliated with UPEI and DGI, as such we need to codify how design and development is done, which will ease maintenance, allow us to indoctrinate new developers into the project and allow us to accept patches from the wider community.
Islandora is a long term repository solution that needs have a consistent interface. Custom code should be unaffected by upgrades. Interfaces and implementations should be developed separately to allow for maximum flexibility while remaining consistent. By developing the interfaces as design documents, and getting community and developer feedback, we help to ensure that the interfaces developed will be widely useful.
The interface is the public facing objects exposed to the wider community to be used by outside applications. The interface needs to be as consistent as possible. This process is never perfect, and when API breaking changes need to be made, we will develop new versions of the API, to maintain compatibility. Multiple implementations can be developed and injected into the interface. New interface versions or new implementations can be added later to support future growth without a major impact. Old APIs will be deprecated and can be removed at a later time, when their usage falls off.
Web users are accustomed to fast load times when browsing are not willing to wait more then 10 seconds. It might not always be possible to load all the data in that window but we can acknowledge the user and display partly loaded pages. This goal can come into conflict with the other goals on this project, but its importance to the end user experience is such that speed must always be kept in mind.
People are notoriously bad at profiling code and to make it worse the performance problems are often in the design. With that in mind optimizing code should be a last resort. Caching, lazy loading, concurrency and performing expensive operations on writes should be considered when designing a feature. By creating a well thought out design before the feature is implemented we can help to mitigate some of the speed problems that we will face.
Writing tested code is the only way to deliver large projects on time with any measure of success. It might seem like extra work at the beginning but drastically reduces the overall cost of the project in the later phases when bugs become evident. Testing helps to ensure that changes can be made to the software confidently, without regressions, allowing us to respond quickly when changes are needed.
Each feature should have use cases associated with them that defines what a function should look like and how it should behave. The uses cases can then be used to generate tests so that as development progresses everyone is assured that each module is meeting its contract to the users.
Unit tests isolates each component of a program or module to see if the component is functioning correctly. The unit tests use the components interface making it easy to see design flaws early own and enforce that the interface remains consistent.
On the Drupal side, we will use Drupal’s simpletest framework will allow us to bootstrap a Drupal environment and do things like submit forms as multiple users, allowing us also to test at a higher level.
Islandora needs to be able to handle data ranging from a handful of small PDF files to terabytes of mixed media content. Islandora supports everything from small libraries that may only get hundreds of visitors a week to large scale repositories generating may thousands of users., large users bases, large data files that continue to grow and transformations that become more complicated.
Front end caching servers, memcache, distributed processing, distributed content delivery services (ie: image loaders services) need to be supported for large scale systems without forcing small scale users into extra complication. This will allow users to grow their Islandora Instance from a small initial repository, as IT staff and resources are allocated.
Grouping these seemingly conflicting goals together is intentional. Often flexibility goes hand in hand with complexity. Allowing the flexibility to solve a problem in any way means that every developer on a project will solve a problem in a different way. The goal here is to balance flexibility and simplicity.
Islandora needs to be flexible for developers and users allowing complex problems to be solved in standalone modules, providing a pluggable architecture and allowing developers to meet users needs without modifying the code functionality of Islandora. This flexibility also means simplicity as modules are small and focused, solving a particular problem, rather then every possible problem.
The API should be simple, well documented and easy to use. There shouldn’t be a million ways to accomplish the same task. This allows developers to quickly get up to speed on the project and begin solving users problems. By abstracting away the complexities of the lower levels, we allow developers to work without worrying about the implementation details until they need to.