While TAR files and segments are a coarse-grained mechanism to divide the repository content in more manageable pieces, the real information is stored inside the segments as finer-grained records. Here I zoom in the segments and show the binary representation of data stored by Oak in the segments. It is not strictly necessary to know how segments work in order to understand the content of this post, but if you feel lost you can refer to my previous entry describing segments in greater detail.
I recently started working on a big, monolithic project. In my opinion, this project is a good candidate for an aggressive modularization effort. Let’s imagine that someone is arguing against this effort, and let’s analyze his statements. Are all of these statements true? Can modularization really provide some benefits to users and developers?
Here is described the phisical layout of a TAR file as used by Apache Oak. First, a brief introduction of the TAR format is given. Next, more details are provided about the low level information that are written in TAR entries. Finally, I describe how Oak saves a graph data structure inside the TAR file and how this representation is optimized for fast retrieval.
Sooner or later everyone needs a cache in its application. There are many caching strategies available to the wise developer: least recently used (LRU), most recently used (MRU), least frequently used (LFU), and a lot more. In this post I want to discuss about Magazine, a Node module implementing a flexible LRU cache.
to an array to create a new output array with desired properties. While this is
a well known approach, this may not be the most efficient one. In the first
place, the input array must already be in memory. This also means that the array
must be known in advance: abstractions like infinite arrays or infinite
sequences are not possible out of the box. Here I present a simple abstraction,
inspired by pure, lazy, functional languages, to model a list and some high
level operations on it.
Actually, functions can take any number of parameters via the
special variable. It is up to the developer to support different combinations of
parameters by checking their type and handling them correctly. Good news is that
this logic can be encapsulated and reused to easily build polymorphic functions.
I’m not the first one to write about this topic, and someone before me already wrote books about it. The reason behind this article is that I’m facing some design issues in a piece of code I’m writing, and probably explaining my ideas will help myself more than anyone else.
Jenkins allows you to extend the system by writing new plugins, which can be installed into the CI server manually or automatically. Tooling provided with Jenkins helps in writing, validating and testing new plugins but the build process of a Jenkins plugin is never described in detail.
The Sling main servlet is the component which handles incoming requests after authorization is correctly performed. When the Sling main servlet is called, a resource resolver has already been stored into the request. The resource resolver, together with other components and services, will be used to perform the real handling of the request. The most important role of the Sling main servlet is to integrate every required component with the OSGi HTTP Service, and coordinate them to correctly process a request.
The authentication code in Sling is maybe one of the most complicated part of the whole project. It is a a critic functionality but, at the same time, it provides a lot of flexibility and it is a good example of an extensible API.
When you write a bundle for Sling, or for another OSGi based application, you are faced with a dynamic environment. Bundles and classes can come and go, and you should keep track of events emitted by the framework to carefully update your point of view on the state of the system. Moreover, a bundle can’t usually get references to classes from unknown, unimported packages.
This process starts when Sling receives an HTTP request and it correctly finds a resource for the request. When this process starts, Sling already has the following information:
Sling is a web framework built on top of OSGi. Every addition to the framework, be it your own application or an extension to the framework itself, is packaged and installed as a bundle. This article tries to explain the basic steps to go up and running with your first Sling bundle.
When developing Node applications is often needed to implement a plugin system. You want to do this to enable other developers to provide features to your software without cluttering your code base, and to define a clear separation between core and externally-provided features.