This document lists, describes and argues the basic insights and principles that drive the decisions in this project.
It is explicitly meant to trigger some like-dislike emotions in order for people to either resonate, find motivation and participate or else refute, classify and move on.
For a full list of features (which we think should have a lesser 'binding' power to the project) you should read the (unfinished) feature list.
This project is about Web Application Development. Kauri aims to bring a solution to everybody, every role involved in a project that involves web application development. If your needs do not include developing an application with a web interface, then Kauri is probably not for you.
To everybody: "Welcome!".
The term 'holistic' refers to the belief that certain aspects of a complex matter (the 'whole' , e.g. project) cannot be captured or explained by only looking at (or making the sum off) the different composing parts.
Web Application Projects involve quite a number of different profiles, experts and stakeholders, and often each of those have a fragmented view on the project's goals and deliverables and are witness to only limited parts of the team communication.
Sure enough given the mix of people, their schedules and priorities, there are quite a number of aspects of the project's management that naturally require some out-of-band (or -role) communication ("looking over the cubicle wall") and organization supporting tools (issue trackers, mailing lists, status reports, wiki's, and whatyouhave) but the point we want to make here is that, often times, there is just no single "project source/artefact repository" available which is the unifying and final source where the work of all project team members is living and growing.
This is often a consequence of a chained way of working where the work result of one actor is nothing more than input, a basis of rehashing and re-organizing for the next actor involved. In the end this leads to confusing communication, wrong expectations, work being redone, longer roundtrip times and frustration.
The archetypical solution to this situation is to build a central system with a set of established contracts declaring the "Separation of Concerns" (SoC). While obviously correct in theory the practice of these solutions often seems to be foregone at the actual project level: a practical CoS-style is adopted, a Collaboration of Specialists:
This is about more than just making all members check-in check-out from the same code repository. This is about making sure that their respective deliverables build up the actual working web site, service or interactive experience, and that they build up from the work of the other project actors. It assumes a flexible run-time that can host and process the various developed resources that together make up the actual project.
Software projects tend to mature through some different steps on their way from inception (over analysis, design, prototyping, rethinking, testing, profiling and implementation) to completion. At each of these stages various people will be looking into what is already there, interpret what is still needed, comment on existing parts, and suggest or apply the needed changes to get to the desired end result.
During this process, parts of work are completed as previous samples, place-holders, stubs or mocks are replaced by actual running code, introducing interactivity in the project. By enabling this gradual completion of the complete project the mentioned run-time environment can ensure the complete development team keeps flocking together around a growing shared system of runnable code.
This very same flow of the "growth and maturity" cycle has to pass across the boundaries of public releases of the web interaction layer. Not only must there be a priori thoughts of defect resolution and maintenance, as new releases are bound to emerge there is also need for controlled upgrades and / or backwards compatibility.
New versions should able to be actively developed in parallel, while different parts of the system can keep relying on existing solutions.
The pendulum of opinionated web application development has been favouring for a while either the browser, or the server side as the most prominent, logical, stable, future safe or trustworthy environment to host the bulk of the solution logic.
Being resilient to the next swing of that pendulum nicely aligns with our earlier suggestion that the various web aspect experts should be happily collaborating on the project. Allowing each of those expert domains to directly contribute to the end solution should naturally leverage the natural benefits of the various platforms in the mix. Kauri wants to provide foundations for both the browser-, and the server-side, which nicely align and integrate with each other, as none of both platforms allow you to build the entire solution.
The only aspects of the web project we want to cater for are the ones related to the actual development (production). Reporting, planning and management aspects are not included.
We are thus in search of a 'system' (mix of platform, framework, libraries, guidenlines and tools, even some methodology) that brings practical answers to the common development use cases in web projects.
The common properties of these development use cases are:
The expected items making up the system are foreseen to be:
After advocating the holistic approach it is time to give some reductionism a place as well. The mentioned holistic drive primarily wants to force collaboration between all members of the multi-disciplinary project team, and make sure each of their deliverables can be 'activated' in the system as directly as possible.
Practical experience with large and complex projects however learns that reducing the overall complexity in smaller chunks is a great strategy for keeping those projects conceivable and manageable. Each chunk will typically have his set of experts working on them according to predefined interfaces between them.
Modules and components are often cited as a desired architectural means to achieve reuse. In practice however we believe such advanced reuse is less important (nice if ever achieved, but in the fast moving web space seldom witnessed) than the more immediate gains of reduced complexity, gained consistency, and higher adaptability (needing to change certain things only once). The primary focus for building modules is to make them usable, if done well reuse should follow.
These web modules in our vision are self-contained, separately released bundles that declare available services and (static) resources. As such they will have a common natural interface upon which other modules can rely. Some management (or injection) of dependencies between them will be required. These dependencies should be expressed in a web-friendly or web-natural manner that allows a high degree of open networking flexibility. Things we think about in this respect:
Looking at the web as one big system of many very different, loosely coupled but nicely (well, mostly or at least possibly) integrating services and systems, we find another reason for giving modularity a place. The design option of choice for big IT integration projects is not to redo and centrally combine all aspects, but rather to loosely couple, and only to foresee a unified interaction mechanism. This allows diversity and specialization, and even applauds the inherent autonomy of different systems at the cost of some extra runtime checks and lookups.
In other words: the reality of the web, and the future of complex and large scale IT systems tell us to foresee a (web inspired) mechanism for different modules to call upon each other. Thus various information pieces can consolidate into a unified view by aggregating, combining, filtering (and/or temporarily or permanently just reporting on missing past dependencies) resources from different modules.
The main approach we see to that flexible web-aware wiring is ensuring a web focussed strategy from the ground up. The way the Resource Orientation Architecture (term coined in O'Reilly's Restful Web Services) describes resources that are represented, located, named, addressed, and managed through a uniform interface is largely the direction we're going to. Being the 'grain of the Web' we think it should be 'grain of web-based project development' as well.
As some extra argumentation, we find this resource orientation matches very well
This is what the Kauri Vision is about: better tooling for better webapps.