ApolloGeese/CLON
Read on or Download a Release immediately
ApolloGeese is a design philosophy, a collection of modules relevant to web development and a simple object-notation language to loosely couple them together according to this design philosophy.
The current proof-of-concept implementation has been done in Mono C#.
Projects already using ApolloGeese/CLON
Dorpinator
Generates usually fictional dutch town names. View website
DeelDoos
A simple, largely browser based HTTP filesharing tool. View Repository
MegaLAN website
Information and registration portal for the RuG FMNS MegaLAN. View website View repository
Crash and Compile
Crash and compile registration and score system. View website View scores
Wiki Module
Versioning Wiki, uses MySQL and above Login module. This site use it View repository
Login Module
Usename/password login Module, uses MySQL. View repository
But why
Or: Defects in modern software architecture
In any given software design, more than 90%* of the program flow consists of merely a handful of similar elements chained together in a hierarchical fashion, exchanging typically trivial amounts of information. Tight coupling however negates this effect and makes software projects less sustainable.
* 90% of percentages are just made up
Creative limitations
By restricting the amount of intricacies a developer may introduce to a software product, and offering only very abstract components and relations, a gain in development time may be achieved. An even larger gain in quality may be achieved due to the reuse of components that have already been implemented, and tested many times thereafter.
ApolloGeese/CLON aims to make this idea practical using a framework and language (more on the latter, later.)
Basics of the Philosophy
At the basis of the design philosophy lay Services and Interactions. Services are the active components of a software design. Interactions provide the connections over which Services may exchange data.
A developer using ApolloGeese only needs to specify what Services are being used and where they should connect; underlying implementation and negotiation on the type of Interaction used, is transparent to the developer.
Services
Services in short, provide:
- Functionality.
- Means of initial configuration of this functionality through a constructor-like call.
- A single entry point used to activate the service and provide it with context produced by services that came before it.
- Multiple named exit points used to propagate richer context to hierarchically downstream services, by means of Interactions
Interactions
Interactions in short, provide:
- Hierarchy and Communications.
- Storage of arbitrary information on a key-value basis.
- Means to access and mutate information about on earlier interaction in the hierarchy.
A selection of existing services
Even though the design pattern is quite universal, it's been mostly used to build modules for web development, such as:
Connecting Services
It would be most easy to settle with the philosophy and the modules, and to couple them together using existing development platforms such as Python, C# or Java. You could do this, it would however come with two disadvantages:
- Existing languages come with a payload of features we don't require here
- The temptation would arise to implement irresponsibly tight couplings like we're used to doing with these languages.
CLON
Aside from sounding like an STD capable of traveling through space, CLON is the language that aims to tackle these issues by being:
- Light and simple
- Like, Really simple
- Strictly object oriented
CLON is short for 'C-Like Object Notation', and shares some traits with JSON, the most notable difference being references.
CLON may be used to string ApolloGeese services together, like we did for this website as follows:
/* agsite.conf, root configuration of */
/* website about apollogeese begin */
/* reading at 'agsite' (bottom); */
/* the parser won't guess ahead */
{
instances = {
cachedexample = Cache() {
begin_branch = Module(
f"codeformat.conf@highlight"
) {
codesource_branch = Template(
f"agsite.conf");
};
};
homepage = Template(f"home.html") {
example_branch =
instances.cachedexample;
};
content = SiteSubsection() {
main_branch = instances.homepage;
learn_branch = Module(
f"learn/learn.conf@learn");
eatemp_branch = Write(format = "");
wiki_branch = Template(
f"barcapsule.html"
) {
content_branch = Module(
f"wiki/agwiki.conf@begin",
baseurl = "/wiki");
};
};
agsite = Sessionizer("session") {
http_branch = SiteSubsection() {
default_branch = Template(
f"skeleton.html"
) {
content_branch = instances.content;
style_branch = Module(
f"style/style.conf@style");
};
static_branch = Fileserver(
allowedmimetypes = {
svg = "image/svg+xml";
css = "text/css";
js = "text/javascript";
jpg = "image/jpg";
html = "text/html";
png = "image/png"
},
rootpath = f"static"
);
ckeditor_branch = Fileserver(
allowedmimetypes = {
css = "text/css";
js = "text/javascript";
jpg = "image/jpg";
html = "text/html";
png = "image/png"
},
rootpath = f"wiki/ckeditor"
);
};
};
};
}