Page 125 - Building Digital Libraries

CHAPTER 5

Mobile Application Development

Libraries have largely stayed out of the mobile development space, choos-
ing instead to purchase programs that can turn application websites into
stand-alone mobile applications. But we think that this space is too big
to ignore. As of the time of this writing, more people access the Internet
through their mobile devices than through a traditional desktop environ-
ment. And in developing countries, mobile services are the only method of
Internet access. As mobile systems continue the trend of creating increas-
ingly walled gardens for their users, cultural heritage organizations will be
forced to make decisions around mobile development. And this will be hard,
since the mobile development of services, at least in the current paradigm,
is very local.

Applications Continue to Become More Micro

By now, individuals in the digital library space should be very familiar with
the microservices development model. Since 2010, a number of papers and
services have been created utilizing these concepts, in an effort to reduce
an application’s complexity and footprint. We believe that this process will
continue, as library software developers shift away from developing domain-
specific solutions and move to leverage existing solutions created outside of
the library community in order to solve large problems. This development
model is illustrated in the Fedora 4.x development. Fedora 3.x was a large,
monolithic object store that was designed for the long-term preservation
of digital objects. When the community began development on Fedora 4.x,
the decision was made to shift much of the core architecture outside of the
library community. This meant that Fedora 4.x development would entail
the development of a framework and messaging system around other open
source projects and technologies to achieve the same goal as Fedora 3.x. The
benefit of this was that the cultural heritage community would no longer
need to maintain the entire application stack, but only those parts that were
unique to the Fedora application. This type of development carries with
it certain risks, since it makes tools dependent on a much wider array of
dependencies, but it also shares the larger cost of development.

Deeper Reliance on Interpreted Languages
and JavaScript

Digital library development has always been separated into two camps:
system work that was primarily coded in Java, and process work that was
created in a range of interpreted languages (such as PHP, Ruby, PERL,
or Python). This is still true for much of the core software used in digital
libraries, but it is coming to an end. The cultural heritage development
community has been slowly shifting away from using Java as a develop-
ment language. Some of this might be due to the change in ownership of

110