Uncle Unc 0.25.5 review
DownloadUncle Unc is an application that provides an integrated view of structured data sources
|
|
Uncle Unc is an application that provides an integrated view of structured data sources. Using a very flexible and powerful representation model, many services can be represented in Uncle Unc.
Uncle Unc is a framework for network data-sharing, enabling remote administration and access to a range of services from a range of clients, using a simple text-based protocol that isn't tied to any platform, operating system or programming language.
Uncle Unc is a toolkit for agile development of interfaces to network services that are easy to maintain, and will grow as the service grows.
At the heart of Uncle Unc is a small generic specification of what a information-based network service might look like. This specification is very generic, and free of reference to any specific technologies or buzz-words.
It is based on the simple observation that much of the time we spend with computers is spent organising and categorising data, pushing data from one box to another, and invoking actions on that data. Most user interfaces attempt to represent this activity for a single type of data, such as a mailbox, a filesystem, a relational database, a network of computers or a music collection. Uncle Unc provides a framework that makes it easy to interact with any data source.
If you feel constrained by the user interfaces you are using (or developing!), or frustrated by having to use a poorly-designed user interface for a particular task, then Uncle Unc may turn out to be a good friend!
Uncle Unc is based on the simple observation that much of the time we spend with computers is spent organising and categorising data, pushing data from one box to another, and invoking actions on that data. Arguably, we ought to spend less time doing this sort of thing and get out into the fresh air more! At the very least, we should be able to do it efficiently and effectively. The more energy we expend on wrestling with the user interface in order to get these low-level jobs done, the less we will have to deal with the high-level problem-solving tasks that can make the difference between work and gainful productivity.
Let's call this low-level categorisation activity as 'stamp collecting', at the risk of offending philatelists. Most user interfaces attempt to represent stamp-collecting activities for a single type of data, such as a mailbox, a filesystem, a relational database, a network of computers or a music collection. Uncle Unc provides a framework that makes it easy to interact with any data source at this level.By doing it once, we can take the time and effort to do it well, so that it doesn't intrude on the user's activities unduly.
Computing is a rapidly changing field, full of powerful new uses for computers such as digital multimedia, realistic graphics and artificial intelligence. And yet much of the time that we use computers, we are performing essentially the same stamp-collecting tasks that we did twenty years ago.
Even when dealing with the new high-powered uses of computers, this is the case. How much of a digital music player program's code is devoted to playing the music, compared to sorting through and organising album playtracks (and which does the user spend most of their time doing?). 3D graphics and neural network designer applications have a similar requirement to present their internal information in a useful way to the end-user.
There is currently little cohesion in the way that software developers address these tasks. Each application codes its own listings widgets. Some have sortable fields. Some have filters. Some can divide the results into pages. Most do some things quite well, some badly, and some not at all. Most will present the interface in a single medium - as a desktop application, or a HTML web interface, a java applet, a flash movie, or whatever. Most will run on a limited number of platforms, Operating Systems or browsers.
This situation restricts the exposure of the application behind the interface, by tying it to that interface. It also limits the exposure of a front-end to a single application. The proverbial wheel is frequently re-invented, and often under tight pressures of time and resources, with less than desirable results.
Uncle Unc is an attempt to develop a generic component framework that allows many different structured data-sorting tasks to be harnessed in a manageable way. A small central set of open interfaces serve as a broker between any client and any service, giving the owners of the network the maximum degree of flexibility. In the language of Desiogn Patterns, Uncle Unc implements a bridge pattern between list-like clients and list-like servers.
Here are some key features of "Uncle Unc":
A common set of interfaces are provided in the java programming language, and the framework has been developed to make it easy to expose any java object as an Uncle Unc service, and to control what gets exposed and how.
Network communication between clients and severs is done using XML, opening the door to non-java programs. Over time, we may develop more detailed frameworks for interoperability using PHP, Python, .NET or other popular programming languages.
Clients and servers are decoupled. That is, a client that can understand one service can understand any service. A service that can talk to one client can talk to any client. This results in a very efficient path to network-enabling a service across a range of platforms, or allowing access to network resources from a new type of client.
This increases the incentive for developers to provide new capabilities to the system. A widget set that provides a better view of a list of items does so for files, mail, log file entries, databases, newsgroups, etc. without any reworking. Similarly, a new backend service that delivers an Uncle Unc interface will enjoy exposure on all Uncle Unc client platforms (with plans afoot to cover web front-ends, smartphones, and scripting language access as well as the desktop clients).
The content of the user interface layer is directly defined by the properties and methods of the back-end service. As the back-end service evolves, there is no need to recode the GUI (or other UI), simplky the skeleton used to support it. Even this can be automatically generated from the back-end systems objects. Agile development is supported and encouraged in this way.
Defining the UI structure directly from the back-end has the further advantage of providing a good fit between the two. A hand-coded UI may omit certain capabilities of the back-end, because they are hard to express using an ad-hoc composition of low-level widgets such as textboxes, tick boxes and drop-down lists.
The UI is built around an open-ended description of the structure of the service that one is interacting with, rather than expressing a set of fixed pathways of interaction. As such, it supports a flexible, problem-solving approach by the end-user, rather than a purely mechanistic one.
Uncle Unc 0.25.5 keywords